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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-15 15:47:30

Gennadiy Rozental wrote:
> "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. 

In the context of translation units: 

    interface = header
    implementation = source file

In the context of classes, functions or templates thereof:

    interface = declaration
    implementation = definition

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

OK, I see. But it doesn't really apply here, because a non-templated declaration generates much more and heavier dependencies than the defintion.

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

...and all translation units that use that IO routine need a rebuild once another printable type is introduced. I'd never call a design like that "elegant", regardless of the scale.

Keep in mind that "good practice", "common practice" and "practicability" can refer to different things, though ;-).

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

It depends. Surprisingly, most compilers factor out similarities among template instantiations pretty well. And of course you can write non- (explicit or implicit) inline functions.

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

The v stands for visitor (I just noticed, you used v for variant, sorry for the inconsistency) - basically the same kind of thing we'd use with Boost.Variant, so I omitted it just like you did.

Regards,

Tobias