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