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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-15 13:49:40

Gennadiy Rozental wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message 
> news:elu6fo$ib2$1_at_sea.gmane.org...
> 
>>Gennadiy Rozental wrote:
> 
> 
>>>Here is my logic:
>>>
>>>we should prefer to minimize dependency,
>>
>>Where are we doing that? A template written towards concepts has no 
>>dependencies while a separate-translation-unit-solution depends at least 
>>on vector,
>>variant
> 
> 
> In part yes. But usually primary source of dependencies is not an interface, 
> but implementation. 

What?! Dependencies in the interface are the worst there are, because they transitively apply to any other component that uses the interface. Would you elaborate, please?

> So in this regard usually it's more preferrable to hide 
> implementation to coding in generic concepts. 

Not at the price of compromising extensibility and adding unecessary dependencies to the interface. 

It only makes sense to use a translation unit if there is some benefit. There is none here - not even the fixed costs of compilation will armortize (dependency scanning of the build system, compiler startup, etc.) and I guess it won't.

> Also STL components are not so 
> much an extra dependancy anyway (they are present in many/most non-trivial 
> translation units anyway)

Maybe (although I usually try to stick with a stricter policy regarding header dependencies) ...

> 
>>and whatever types that variant is specialized with.

... BUT this ^^^ is the real problem.

> tuple will depend on the same types as well.
> 

    template<class Tuple> void func(Tuple const &); 

does not depend on any type that'll be in the tuple (and that's the kind of interface that would usually accept a Fusion tuple).

<snip>
>>
>>Well, the statements from your OP read pretty general to me (and, excuse 
>>my bluntness, these two in particular are just plainly wrong in any 
>>context).
> 
> 
> How are they wrong?
> 
> 2. ...
> Let's say you have record with 10 optional elements. tuple based solution 
> will end up compiling in anything from 1 to 10! different versions of the 
> same function, while offline version will be only one. Also in case if you 
> always want output in the same 10 column format I dont see easy way to 
> implement it using tuples.

We can take an arbitrary Fusion tuple and iterate it. Why should we be limited to a fixed number of elements?! 

Also, only the templates that really get instantiated end up in the binary and ultimately there are no functions at all and things will be inlined. 

Please note that Fusion tuples do not store any dummy elements up to some maximum, or so (in case that's what you believe).

> 
> 3.  ...
> If you take tuples by value you will end up copying huge structures. 

It's much worse to copy std::vector, because we'll need dynamic allocation on top of the copying, which will never armortize for just few elements. Also we'll have to copy more bytes, N*sizeof(largest) instead of sum[N,i](sizeof(T_i)).

<snip>

>>Yes, we shouldn't blur the clarity. The Fusion solution is simpler and 
>>cleaner (just implement both ways and you'll see).
> 
> 
> Unfortunately I am not well versed in tuple/fusion interfaces. Lets say you 
> have comparatively expensive overloaded output operation foo. BOOST_FOREACH 
> solutions would look something like this (ignoring header line)
> 

<code>

In Fusion it's:

    fusion::for_each( seq, v );

Regards,

Tobias