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

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

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

I am not sure what is unclear. If you put implementation into header you not 
only bring dependencies caused by types used in interface, but also all the 
staff that is used by the implementation.

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

Looks like our primary misunderstanding is that we are talking about 
different initial points/different problem domain. If we are talking about 
comparatively simple generic component for let's say csv format output, that 
could be used by completely different development teams I would easily agree 
that tuple or similar is the best approach.

If I am writing component to be used in my project for the the same output 
generation I probably prefer variant instead.

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

So if I have 100 different calls to the output function  I will endup with 
100 different instantiations instantiation, right? And even in case of 
inlining my code size would be 100 times more?

> and ultimately there are no functions at all and things will be inlined.

Non nessesarily, It all depends on complexity of the output function. One of 
the compiler I was using rejects doing inlining under any optimization 
options if there is a throw statement. Another one does do inlining, but the 
resulting version works visibly slower than the one that does not.

> In Fusion it's:
>
>    fusion::for_each( seq, v );

Um, where is an actor here? Meaning where is the call to an output method

Gennadiy