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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-12-14 23:14:33

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message 
news:els60p$kdv$1_at_sea.gmane.org...
> 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).

Here is my logic:

we should prefer to minimize dependency, unless performance in visibly hurt 
in performance critical area => we should prefer to place implementation in 
cpp files under the same circomstances => we were talking anout output 
operation, so performace is
a) not that critical
b) mostly lost in syste i/o

=> i/o operation we should prefer to implement offline

In other words: for the problem at hand inline implementation is 
disadvantage.

> (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).

So would I

>> 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.

In case like this we should be using  snart_ptr<some_huge_class> instead of 
some_huge_class as a member of tuple. But for the task at hand I don't see 
this as a real problem anyway.

>>
>> 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.

Again. It's probably applicable for the performance critical area. For the 
output operation I would stick with BOOST_FOREACH or stl algorithm.

In my experience performance critical tasks are comparatively rare and we 
should not blur the clarity and simplicity for no particular reason.

Gennadiy

P.S. please do not take these posts as a critique of the fusion lib, I just 
do not want us to be carried away by it's power.