In article <C8MGGM.GB5@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>
>If there can only be one definition of each template of a given name in a
>program...

Right.

>In any
>case, practical implementations violate the draft standard one way or another,
>or force the programmer to violate the standard.

Gee!  Somebody noticed! :-)

>Is the intent for the compiler to maintain an Ada-style library of partially
>compiled templates?

It appears so.  My understanding matches yours... i.e. that the way the
section on templates is worded, implementations may indeed be required
to perform template instantiation across separate translation units.

Given that separate translation units are generally compiled at separate
points in time, the clear implication is that C++ implementations are
expected to maintain an Ada-style "memory" of certain things (i.e. template
definitions) which were processed sometime prior to the current compilation.

I don't know how many implementors and/or user have really noticed this yet,
and I have even less knowledge of how many implementors and users think
this was a good idea.  For my part, I think this definitely takes us very
very far away from the simplicity of C indeed.

> If so, will the standard address how such libraries should be managed?

We'll have to wait and see.

  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 you have it.

>I don't think any of the existing compilers fully implement what this
>section requests.

Cfront certainly tries.  Other implementations have been rightfully hesitant
to add yet another (link-time) pass.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgC907o9.7zs@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>Is the intent for the compiler to maintain an Ada-style library of partially
>>compiled templates?
>
>It appears so.  My understanding matches yours... i.e. that the way the
>section on templates is worded, implementations may indeed be required
>to perform template instantiation across separate translation units.
>
>Given that separate translation units are generally compiled at separate
>points in time, the clear implication is that C++ implementations are
>expected to maintain an Ada-style "memory" of certain things (i.e. template
>definitions) which were processed sometime prior to the current compilation.
>
>I don't know how many implementors and/or user have really noticed this yet,
>and I have even less knowledge of how many implementors and users think
>this was a good idea.  For my part, I think this definitely takes us very
>very far away from the simplicity of C indeed.

 So does multiple inheritance. If C were adequate
for modern programming requirements, no one would bother with C++.
After all, there *is* a C standard, and a very good one too.
>
>> If so, will the standard address how such libraries should be managed?
>
>We'll have to wait and see.
>
>  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 you have it.
>
>>I don't think any of the existing compilers fully implement what this
>>section requests.
>
>Cfront certainly tries.  Other implementations have been rightfully hesitant
>to add yet another (link-time) pass.
>

 Borland certainly incorporates this into the *linker*.
(With some bugs :-) Cfront doesn't, because it has to work with
all manner of dumb linkers.

 The Working Paper lists 8 steps of translation:
of these, the 7th is compilation and the 8th is linkage.
(The first 6 steps are all preprocessing :-)

 Inserting an extra stage into the model between
7 and 8 appears more or less necessary given

 a) template instantiation
 b) dumb linkers required at stage 8

That means that stage 7 can produce output which is not
linkable, and requires processing by stage 7 1/2 to get
linkage object modules.

Stage 7 1/2 can do other interesting things, such as resolve
order of initialisation issues by doing dependency checks.

But at the moment there is no stage 7 1/2, so the committee
has a bit of a problem, because there is no place to 'put'
the specifications controlling something that is
clearly more than the compiler (which handles one
translation unit at a time) and the linker (which
has to be 'dumb' for compatibility reasons).

That is, the language appears to require processing which
the translation model precludes. Something has to give :-)


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

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.

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 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?

Thanks,
- Brad

--
Brad Daniels  ` |  "If money can't buy happiness,
daniels@neosoft.com  |   I guess I'll have to rent it."
I don't work for NeoSoft, and |  - Weird Al Yenkovic
don't speak for my employer. |

In article <C8MGGM.GB5@sugar.NeoSoft.COM> daniels@NeoSoft.com (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   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.