Thanks Brendan (and all others)!
As far as I can see there are less side-effects than expected. To give
more background infos (I should probably supplied before):
- It's a bigger project split into modules. These remain separate as
libs.
- We use a build-server. To be on the safe side we will remain
building the 'traditional' way on it. Maybe we should consider distcc
for it!
- We use cmake as build-system. The developer can either generate
normal or 'fast' makefiles. You could tell them to test the code under
both conditions.
On 26 Apr., 00:13, Brendan <catph...@[EMAIL PROTECTED]
> wrote:
> This will probably speed things up on a single processor machine when
> you need to rebuild the entire project since you won't instantiate the
> same template multiple times only to have the linker delete all, but
> one copy. However, there are better ways to speed things up, and your
> approach will break things (as I mention later). Also, 90% of the time
> your approach will actually be *slower*. This is because, every time
> one of those files is updated, the *entire* project will be rebuilt
> under your schema. So you really only get a performance gain after a
> checkout, and not when recompiling after editing individual files,
> which would normally only require you to recompile that specific cpp
> file and relink it.
This is indeed an issue and directly addresses the build-time
argument. I could imagine to only "fast-build" other libs but build
your own lib traditionally (you are currently working at) if we can
tweek cmake this way.
> Instead, your build process can be multithreaded. Both make and visual
> studios 9 sup****t this out of the box. Or better yet, you can use
> distcc or similar process and have your build done on a cluster.
On all the developer's boxes it will be hard to compile with distcc.
Actually linking takes the longest time if you just re-compile the
file you are currently working on. On the other hand if you have to re-
build all after a checkout it takes about an hour.
> > The question is: once it compiled successfully (no duplicate
> > definitions etc), is there any side-effect possible? Is the linked
> > library/executable any different than the one produced the 'normal'
> > way?
>
> Yes! In fact, I'm surprised all of your code didn't break immediately.
>
> Static variables and the contents of anonymous name spaces are only
> accessible in the translation unit in which they are defined. e.g.[...]
That was my biggest concern. It seems that the language keyword/
construct 'anonymous namespace' is linked to the work of the
preprocessor and linker, so you possibly break your code.
But if these namespaces are 'merged' and lead to a compiler error, you
can look at the output and fix it. The greatest danger in my eye is an
error or side-effect which you don't realize because the compiler is
silent about it.
> > There is one issue I already can think of: the order of the execution
> > of constructors of static objects (like global variables). Any more?
>
> Well, the order of execution of static objects is normally not defined
> across translation units. You are actually taking something defined
> and making it defined by putting everything in a single translation
> unit. I can't imagine how this would be harmful, except that you might
> come to depend on the order of instantiation which would go away if
> you changed back to the multiple translation unit model.
So to summarize it:
Concatenating all cpp files to one big one possibly breaks
compilation, but if this is fixed (no conflicts), there should be no
unexpected conflicts during linking or execution (am I right?). The
order of execution of static objects switches from undefined to
defined, but as long as the official build is made traditionally, no
one should rely on it anyway!
Peter Holtwick
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
