Francis Glassborow <francis.glassborow@[EMAIL PROTECTED]
> wrote:
> Mathias Gaunard wrote:
>> On 25 avr, 19:13, bor...@[EMAIL PROTECTED]
wrote:
>>
>>> Is the linked
>>> library/executable any different than the one produced the 'normal'
>>> way?
>>
>> It is likely the code generated will be much more efficient.
>
> On what do you base that assertion? Modern C++ compilers already delay
> much code generation till link time. In fact can can imagine that the
> proposed process might result in longer compilation times as data tables
> grow to a size where they need to be paged out. It also increases search
> times as the size of compilation data increases.
I guess we can safely assume that the OP in fact sees a gain in speed
_and_ does not get compilation troubles, otherwise he would most likely
not exploring this approach.
This leaves the problems of changed visibility, and possibly of changed
initialization order - which might be a problem, but usually isn't if
one keeps in mind that "lumping of compilation units" may happen.
> If rebuild times are an issue learn to avoid sucking in more than is
> needed for compiling an individual TU.
I would be surprised if he wasn't aware of that ;-}
Btw, keeping compilation units small _and be serious about that_
basically means not using the Standard Library. Last time I checked (a
year or so ago) I got the following line counts after a single #include
<...> (g++ 4.something):
string : 18781
vector : 11994
map : 12467
list : 11134
deque : 11805
iosfwd : 6462
iostream : 29529
I.e. even "light use" of the Standard Library (string + vector + streams)
gives a 50000 line compilation unit no matter how much "real" code is
in there.
Or, put differently: If you have a medium sized project of 200
compilation units, each containing 500 lines of "own" code with
aforementioned "light use" of the Standard Library you can have
either
200 x (500 + 50000) = 10.1 Mio "compiled lines"
or, "lumped",
(200 x 500) + 50000 = 0.15 Mio "compiled lines"
Also note, that the "lumped" version is only three(!) times as large as
one of the 200 units in the first case. So even if it does not scale
linearily (which it does not...) there's still a nice gain.
[Ah, and I forgot to mention that "cheap" forward declaration of
standard containers is close to impossible thanks to the allocator
template argument and the impossibility to specify default arguments
twice ...]
> In addition the introduction of modules (delayed till a TR after the
> release of C++0x) will make miuch of what you are currently doing
> counter productive.
My second guess in this mail is that we also can safely assume that
the OP has an actual problem, and he has it _now_. I fail to see how
pointing to some "TR after the release of C++0x" helps in this scenario.
Andre'
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
