Re: [boost] If boost::fusion is the hammer, then what's the nail?

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