Re: Can static member variables be declared "inline"?
On Sep 2, 9:14 pm, Juha Nieminen <nos...@thanks.invalid> 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.
That would depend a lot on the compilation strategy used.
Exactly.
Classically each compilation unit (eg. .cc file) is compiled
completely separately and independently into an object file
(eg. .o).
And classically, the implementation code of the template was in
a separate source file, which didn't get read (and compiled)
until link time.
That's everything the compiler might be instructed to do: To
compile one .cc file into one .o file, period.
That's a fairly rare case today. I don't know of any compiler
which supports templates which uses it. Compilers output a
variety of files, for a variety of different reasons.
The compiler does not know of anything else. This is the most
typical situation when compiling with makefiles and the 'make'
utility.
It's not the situation with Sun CC, under Solaris. It wasn't
the situation with the old CC under HP/UX, either. (I've not
had the occasion to see what the newer aCC does). And if memory
serves me right (it's been a long time), it wasn't the case with
the old xlC compilers under AIX, and from what I've heard, it
isn't the case with IBM's Visual Age compilers either.
In fact, the only compiler I know which does it this way is g++,
and even then, there are options and variants which change it.
VC++ generates tons of additional files, but I don't think they
have anything to do with templates, so conceptually, VC++ is
probably similar to g++. Sun CC, HP's old CC and Visual Age CC
all use some form of repository, and cache instantiations.
In this case the compiler has absolutely no way of knowing
where else some templated static variable might be used, so it
simply has no other option than to instantiate it in that
object file.
It can look in the repository, and see if the template has been
instantiated with the given arguments or not. If it hasn't
been, the compiler instantiates it and adds the instantiation to
the repository (and NOT to the object file).
This is the way templates "classically" worked.
It knows of no others. It can't even know what the object file
will be used for. Maybe it will not be used to link an
executable directly, but rather create a precompiled library
(.a or .lib in many system) or a dynamically-linkable one
(.so, .dll). In theory the object file could even be used to
link it to a program written in a completely different
language (although only in theory, as in practice this happens
quite rarely). So in short, it has no other option than to
make the instantiation to the object file.
Which is why most compilers don't.
Is this an "inferior" compiler in your opinion?
In this regard, yes. (Obviously, other issues come into play,
and globally, g++'s support for templates is better than that in
Sun CC. But the compilation model used by Sun is far better.)
Because you talk about other compilers which use a different
compilation strategy as "better".
Well, using some sort of repository seems like a much better
solution, if done correctly. And most of the compilers I've
used have used a repository---g++ and VC++ are the notable
exceptions.
--
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