From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-14 13:43:35
Hi Gennadiy,
sorry for jumping in here. But I believe this post might need a bugfix.
Gennadiy Rozental wrote:
> "John Maddock" <john_at_[hidden]> wrote in message
> news:006401c71f85$12d1a8b0$20570252_at_fuji...
>
>>Weapon Liu wrote:
>>
>>>I personally very like this fancy facility, and that's why I present
>>>these mumbles here to annoy you guys( if so, my apologies go here:-))
>>>Any comments?
>>
>>I can give you one use I have for tuples:
>>
>>I have a piece of boilerplate code that accepts a tuple (of any size) and
>>prints out either a csv file or a boost::array C++ code conaining the data
>>passed.
>>
>>It allows me to output data for graphing, or matrixes of test data very
>>quickly just by creating a short function that returns a tuple, and then
>>passing that function to my boilerplate. If I want more columns of data I
>>just increase the size of tuple by 1.
>>
>>I suppose I could have used a vector instead, but it's less elegant
>>somehow.
>
>
> How the std::vector<boost::variant> is less elegant?
>
> 1. It's could be implemented in cpp file. Your tuple based solution is in
> header right?
Right. It can be both an advantage or an disadvantage depending on what you're up to (modularity vs. genericity).
(Sidenote: If you know how the tuples will look like you can instantiate them explicitly and toast them into a cpp file, but I'd probably go for vector<variant> in case I need a translation boundary for the sake of convenience).
> 2. It allows dynamically sized entries, so you could skip some of the
> default values
> 3. It's as fast of could be even faster since we don't need to pass big
> structures around
AFAIK Boost.Variant calculates the storage size based on the largest object (just like a union does). It also has good reason to do so since heap allocation is an expensive operation.
IOW if we have vector< variant<some_huge_class,int,int> > and most of the variants in the vector are ints we're wasting memory.
>
> The only drawback is that you need to know set of types ahead of time. But
> this is minor IMO and it's quite easy to add an extra type whether a need
> arise.
>
Here's another drawback: Say we want to visit every entry in the sequence and use an appropriate function for each type of thing we find. With vector< variant<...> > we need a) a loop and b) to choose the function at runtime. Both can be eliminated with Fusion and it even takes less code to emphasize it.
Regards,
Tobias