Gennadiy Rozental wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:eluqo4$d97$1@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