(ref.doc)vinoski 150693

Newsgroups: comp.std.c++
From: [email protected] (Steve Vinoski) (Note:
 Vinoski)
Subject: Re: template definitions
Date: Tue, 15 Jun 1993 20:46:32 GMT
Nntp-Posting-Host: srv.ch.apollo.hp.com
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <[email protected]> [email protected] (Brad Daniels) writes:
>My C++ compiler was giving me headaches when I was trying to get it
>to define template instances, so i decided to see what the working
>draft of the standard had to say on the subject.  Section 14.5 says
>"If the definition of a specific template function or specific template
>class is needed to perform some operation and if no explicit definition of
>that specific template function or class is found in the program, a definition
>is generated."  That says to me that you get a definition generated if you
>use a template instance.  The language seems to imply that the intention is
>that the definition generated should be for the entire program.
>
>Earlier in that same section, it says that there must be exactly one
>definition for each template of a given name in a program.  This combination
>of requirements seems to cause problems, and I'm wondering what the intent
>is here...
>
>If there can only be one definition of each template of a given name in a
>program, there can be only one place where a conventional C++ compiler will
>have sufficient information to generate a definition for a specific template
>function or class, that place being the sole place where the template is
>defined.  If the compiler implementors decide to take a more liberal inter-
>pretation and allow mutliple instances of the defining code, there may then
>come to be multiple definitions of specific instances of a template unless
>some kind of cross-module library is maintained.  A compiler writer might
>decide to either generate a file-scope definition of the instance in each
>module needing such a definition, or to provide explicit control over whether
>the template definitions get generated through the use of pragmas.  In any
>case, practical implementations violate the draft standard one way or another,
>or force the programmer to violate the standard.

Some systems generate multiple copies of the required template
instantiations and rely on smart linkers to do the right thing.  Other
systems, such as cfront, rely on pre-link instantiation processing
with repository storage to ensure that one and only one instantiation
is generated for a program.  Glen McCluskey describes the cfront
automatic instantiation mechanism in his February 1992 C++ Report
article entitled "An Environment For Template Instantiation".  (See
also the cfront 3.0 documentation.)

>Is the intent for the compiler to maintain an Ada-style library of partially
>compiled templates?  If so, will the standard address how such libraries
>should be managed?  As it stands, it looks like the compiler needs to do
>a final pass over the generated code before linking to determine which
>templates are needed, then generate definitions of specific template instances
>using some mechanism possibly along the lines of requiring the user to
>specify template sources on the "link" line.

I think the basis of the ARM requirements is that programs such as
compilers are better at keeping track of the template instantiations
required for a given program than a programmer is.  The intent is to
relieve the programmer of the tedium of ensuring that all the
necessary templates have been instantiated.

The wording in the ARM sure makes it seem like an Ada-style repository
is a requirement.  Needless to say, some vendors and users aren't too
happy about that.  I personally have had a very difficult time using
cfront with a configuration management tool (ClearCase from Atria)
because of their differing views of when and why template
instantiations should automatically be rebuilt.  In effect, cfront is
no longer just a compiler, it's a software development environment,
and so it tends to clash with other software development tools.  (I'll
happily provide the gory details about my experiences to anyone who
wants them.)  It'll be interesting to see what the ANSI/ISO C++
committees decide to do with those particular passages in the ARM.

>I don't think any of the existing compilers fully implement what this
>section requests.  Can someone say what the intent is, so that I will
>have some idea which way compilers will be moving on this subject?

I think the cfront mechanism allows a full implementation of what the
ARM says, but note that it isn't cheap.  Firing up the whole compiler
every time a template instance has to be compiled gets expensive when
there are many templates in a program, especially on UNIX where the
compiler typically consists of two or three separate processes.
cfront attempts to reduce this cost by keeping the template repository
around and using make-like rules to determine whether or not a
particular instantiation has to be recompiled, but as I noted above
this mechanism can easily clash with other tools.

--steve

Steve Vinoski  (508)436-5904   [email protected]
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.