Boost logo

Boost :

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

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
>> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at