Re: Can static member variables be declared "inline"?
On Sep 2, 9:15 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
Some compilers do instantiate many times, and
count on the linker throwing out all but one, but the better
ones maintain a repository of some sort, and don't reinstantiate
if they don't have to. (Of course, getting this right is
non-trivial, and earlier versions often failed to reinstantiate
when they should have, or vice version, which has left a bad
taste in some people's mouth.
"vice version" - I like it!
A Freudian slip for vice versa, of course. But you've revealed
enough personal data in other postings for me to suspect that
you've some experience with early CFront based implementations
of templates (any of the Sun CC 3.x, for example), so you know
what I'm talking about: any unexplained error, and you zap the
repository and rebuild from scratch. (The files in the
repository weren't known to make, and the compiler didn't manage
its dependencies correctly---IIRC, it didn't look beyond the
first level of includes. Part of this was doubtlessly due to
the fact that all of the files in the repository had a
"standard" format: C++ source or object format, so the compiler
couldn't maintain all of the additional necessary information it
needed.)
But correctly implemented, it's far superior than redoing
the work n times, with n copies of the same thing floating
around.)
That may or my not be true. In a distributed build
environment, obtaining and waiting for locks on a repository
may impede progress more than simply redoing the work n times.
Some degree of duplication removal will be required
non-inlined copies of inline methods.
That may be a point, and it's certainly relevant to the way Sun
implements its repository. But that sounds like a problem in
the implementation, and not something fundamental. If the
repository were in an Oracle database, for example, I doubt that
you'd find much slow down.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34