From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-15 15:47:30
Gennadiy Rozental wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
>>>In part yes. But usually primary source of dependencies is not an
>>What?! Dependencies in the interface are the worst there are, because they
>>to any other component that uses the interface. Would you elaborate,
> 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
>>>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk