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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-12-14 22:50:42

"Joel de Guzman" <joel_at_[hidden]> wrote in message 
news:elskhd$b32$2_at_sea.gmane.org...
> 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?
>> 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
>>
>> 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.
>
> Another drawback of std::vector<boost::variant> is speed, of course.

This is not clear cut. I do not see in theory why any boost::variant based 
algorithm couldn't be optimized to almost the same code (module type 
switching). On the other hand excessive usage of tuples will cause 
appropriate code bloat, eventually leading to code slow down.

Gennadiy