Marcelo Cantos wrote:
>
> "Steve R. Karmesin" <karmesin@acl.lanl.gov> writes:
>
> >
> > David A. Cuthbert wrote:
> >
> > > Out of curiosity, how does a compiler which does not require the
> > > inclusion of the template code know which templates to generate?

> > It cheats.

>
> There is no need to cheat.  The source file A.cpp can be treated like
> any other C++ source module and compiled into a .o (or .obj) file.
> This is not really a binary object file, but rather something like a
> precompiled header file.

This may require changes to the object file format, and an important
requirement of a lot of C++ compilers is to not modify those formats.

Now, it could be that there are ways to do this without modifying the
format or by small tweaks to linkers and so on.  The point is that the
requirement has been no changes at all.

--
Steve R. Karmesin
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Steve R. Karmesin" <karmesin@acl.lanl.gov> writes:

>
> Marcelo Cantos wrote:
> >
> > "Steve R. Karmesin" <karmesin@acl.lanl.gov> writes:
> >
> > >
> > > David A. Cuthbert wrote:
> > >
> > > > Out of curiosity, how does a compiler which does not require the
> > > > inclusion of the template code know which templates to generate?
>
> > > It cheats.
>
> >
> > There is no need to cheat.  The source file A.cpp can be treated like
> > any other C++ source module and compiled into a .o (or .obj) file.
> > This is not really a binary object file, but rather something like a
> > precompiled header file.
>
> This may require changes to the object file format, and an important
> requirement of a lot of C++ compilers is to not modify those formats.
>
> Now, it could be that there are ways to do this without modifying the
> format or by small tweaks to linkers and so on.  The point is that the
> requirement has been no changes at all.

There is no way to avoid changing the object file format since the
template object file would have to store an IR that kept information
about macros, so it couldn't even use the results of the preprocessor
(save the expansion of #includes).  The textual substitution involved
in macros means that you would require a dumb linker that just passed
the flattened source (ie #includes expanded) in to the compiler.

Or you could have an intelligent precompiler that built as much of the
parse tree as it could and passed a hybrid combination of it and the
unresolvable parts to an intelligent linker that essentially processed
the file as a virtual `code generator' engine.  I'd be surprised if we
saw anything like this in the near future, but the first possibility
is certainly worth considering since it does resolve the dependence on
specific file names and compilation environment (ie: include paths,
etc).


--
______________________________________________________________________
Marcelo Cantos, Research Assistant      __/_   marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT  /       _  Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053    Aus/ralia ><_> Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; funding - RMIT
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Steve R. Karmesin" <karmesin@acl.lanl.gov> writes:

>
> David A. Cuthbert wrote:
>
> > Out of curiosity, how does a compiler which does not require the
> > inclusion of the template code know which templates to generate?
>
> It can know what it needs to generate from the header files.  What it
> can't know from just he header files is the code to actually compile.
> How does it do that?
>
> It cheats.  If you have the template declaration in header file A.h and
> it needs the definition, it automagically looks in A.cpp (or A.cc or A.C
> or something similar).  Whether this happens and exactly how is compiler
> dependent.

There is no need to cheat.  The source file A.cpp can be treated like
any other C++ source module and compiled into a .o (or .obj) file.
This is not really a binary object file, but rather something like a
precompiled header file.

When a module uses templates found in A.h, the compiler has no idea
that the source is in A.cpp.  Instead, the linker is given A.o as one
of the object modules; it finds the necessary symbols in there and
instantiates the template code.  It could also emit the instiated code
into a real object file for the final link and could store this file
in a repository.

Thus it is the linker that instantiates the code which is fully
specified in the A.o file without any need to access source files.
The source file A.cpp could just as easily be called Giraffe.cpp, and
the linker given the 'compiled' Giraffe.o!

Note: I don't know of any compiler that does this at present, though
there are some that use repositories (they use the source code to
build the repository).


--
______________________________________________________________________
Marcelo Cantos, Research Assistant      __/_   marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT  /       _  Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053    Aus/ralia ><_> Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; funding - RMIT
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stephen.Clamage@eng.sun.com wrote in article
<199703121914.LAA03111@taumet.eng.sun.com>...
> If your compiler requires that template sources always be included at
> compile time, that would be the exception rather than the rule. The
> draft standard makes no such requirement. Indeed, there has never been
> such a language rule.
>
> Many compilers, including the very first compiler to implement
> templates, use repository schemes, and have done so for a long time.

True, but including sources at compile time was the only "portable"
way to use templates.  Since there was no standard for repository
usage, there was no standard way of using templates except to
include the source.  Each compiler vendor did things differently.


--

John I. Moore, Jr.          phone:  (301) 924-0680
SoftMoore Consulting        email:  70672.1744@compuserve.com
16233 Monty Court
Rockville, MD  20853-1344
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:

|>  James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
|>  >Stephen.Clamage@eng.sun.com writes:
|>  >|>  If your compiler requires that template sources always be included at
|>  >|>  compile time, that would be the exception rather than the rule. The
|>  >|>  draft standard makes no such requirement. Indeed, there has never been
|>  >|>  such a language rule.
|>  >
|>  >Thank you, Steve.  This is what I have been saying for a long time
|>  >(i.e.: that compilers which required explicit inclusion of template
|>  >implementation sources were broken according to the existing rules).
|>
|>  Out of curiosity, how does a compiler which does not require the
|>  inclusion of the template code know which templates to generate?
|>  Using a specific compiler as an example, Borland 4.52 will happily
|>  *compile* my code, but there will be a link-time error since some
|>  template code will be missing.

I'm tempted to say: that's the implementors problem, not yours:-).

The usual solution has been link time instantiation: the compiler
generates information saying that it needs such and such an
instantiation, and the linker generates it (either from information in
the object file of the compiled template sources, or -- what has more
frequently been the case -- from the actual template sources).

There are problems with this: the main one being, of course, that the
compiler must somehow pass the linker the instantiation context.  Never
the less, it is certainly preferable from the user point of view.

I don't understand the Borland behavior.  If the compiler knows that
template instantiation is now or never, why doesn't it generate an error
immediately, rather than waiting until link time?

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Steve R. Karmesin" <karmesin@acl.lanl.gov> writes:

|>  -- Stephen.Clamage@eng.sun.com wrote:
|>
|>  > Many compilers, including the very first compiler to implement
|>  > templates, use repository schemes, and have done so for a long time.
|>
|>  This has truth to it, but I think the term "schemes" really is correct
|>  here, with "scheme" implying tricky, prone to failure and at least
|>  slightly dishonest. [Note: I'm not calling S. Clamage dishonest!  Only
|>  any current repository techniques that claim to be a real implementation
|>  of what the standard specifies.]
|>
|>  What is going on here is that the standard specifies something that is
|>  really quite difficult and a number of compilers do something that
|>  approximates it in simple circumstances but don't do everything.

Any compiler, using any technique, repository or not, is being dishonest
if it claims to be a complete implementation of the standard; there
isn't any standard yet, and the exact definition of what is required for
templates has been in a state of relative flux, so that one draft will
contradict another.

One might argue (I like to) that until there is a standard (or at least,
until a CD is approved for the next step), one should use the ARM as a
de facto standard.  This would almost require some sort of repository
scheme, however.  It also has the disadvantage that the "context of
instantiation" is not well defined.

|>  That is, suppose you have a header file A.h in which you declare the
|>  templated class A that other things will use:
|>
|>      template<class T> class A { T foo(T); };
|>
|>  and in A.cpp you have
|>
|>      template<class T> T A<T>::foo(T t) { return t; }
|>
|>  Then in file B.cpp you use A<double> and A<int> and in C.cpp you use
|>  A<int> and A<double*>.
|>
|>  When you compile B.cpp and C.cpp the repository schemes need to do a
|>  couple of things:

First, you don't have to do anything when you *compile* B.cpp and
C.cpp.  The entire instantiation can be deferred to link time (and was
in at least one widely used compiler).

Of course, an implementation doesn't have to support separate
compilation at all, at least not in the classical sense.  And as Steve
Clamage once pointed out (in different words), gzip is a conforming C++
compiler, given an appropriate linker.  (The linker must, of course,
decompress the "object" files and compile them, before doing what is
traditionally considered linking.)

|>  1. Find the definition of A<T>::foo.
|>
|>  This is usually done by requiring that if the class declaration is in
|>  A.h the definition must be in A.cpp.  Then it invisibly includes A.cpp
|>  in order to be able to compile foo.  There are various restrictions on
|>  this, mainly that A.cpp can't have any non-template definitions because
|>  when it gets included those look like any other normal declaration and
|>  you get multiply defined symbols.

IMHO: this should be done by reading A.o (or A.obj, or whatever).  A.cpp
gets compiled exactly as if it were a normal library function, and not a
template.

The easiest way to implement this is to just dump the compressed sources
of the template definitions into a special object file record.

|>  2. Put the object code somewhere.
|>
|>  The current repository schemes put the object code for A<T>::foo in one
|>  of B.o or C.o.  A<double>::foo would go in B.o, A<double*>::foo would go
|>  in C.o and A<int> would go in one or the other basically randomly.

I've never seen a repository scheme that does this, but my experience is
limited.  The ones I'm familiar with (HP CC, Sun CC) generally keep the
generated object code in a separate file in a repository directory.

|>  This lets you compile code for which you have all of A.cpp, B.cpp and
|>  C.cpp available to you at the same time.  This is fine if you're
|>  building applications and writing your own templates but there are
|>  problems with third party software and libraries.

Change "the same time" to "some time", and I'll agree that this is
generally current practice.

|>  to give you the source code, either in header files like the STL or in
|>  .cpp files that get automagically included.  If they want to keep it
|>  proprietary they could perhaps do some sort of sophisticated shrouding,
|>  but to the best of my knowledge there aren't any commercial packages
|>  that can handle this case yet, and few companies will have the resources
|>  to invent it on their own.

Sun CC comes with "shrouded" versions of the Rogue Wave library, so
there is at least one commercial package which partially handles this.

|>  The library problem is that you can't "compile" A.cpp into any sort of
|>  intermediate form, pack that together with the intermediate forms for
|>  A1.cpp, A2.cpp, A3.cpp etc that define other template classes, tell
|>  people to link with it and go on.

Agreed.  The problem is you have to jump through a lot of extra hoops to
use templates.

    [I've cut the rest, as the poster is basically asking for the same
thing I have always been asking for.]

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"John I. Moore, Jr." <70672.1744@compuserve.com> writes:

|>  Stephen.Clamage@eng.sun.com wrote in article
|>  <199703121914.LAA03111@taumet.eng.sun.com>...
|>  > If your compiler requires that template sources always be included at
|>  > compile time, that would be the exception rather than the rule. The
|>  > draft standard makes no such requirement. Indeed, there has never been
|>  > such a language rule.
|>  >
|>  > Many compilers, including the very first compiler to implement
|>  > templates, use repository schemes, and have done so for a long time.
|>
|>  True, but including sources at compile time was the only "portable"
|>  way to use templates.  Since there was no standard for repository
|>  usage, there was no standard way of using templates except to
|>  include the source.  Each compiler vendor did things differently.

Except that including sources a compile time didn't portably work unless
all of the functions were inline (and there were no static data members,
etc.).  Otherwise, it caused duplicate definitions with some compilers.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze wrote:
>
> I don't understand the Borland behavior.  If the compiler knows that
> template instantiation is now or never, why doesn't it generate an error
> immediately, rather than waiting until link time?

Hint: template specialization and explicit instantiation.

In some of our in-house library classes, there is a limited set
of parameters that is allowed to some of the template-base classes
(i.e. char and wchar_t).

Instead of having one class implemented using char, and one using
wchar_t, we made a template-class, using the template-parameter in
place of char or wchar_t. When a member-function requires
special handling because of its type, we specialize the function.

In one source-file, we excplicitly instantiate two instances of
the class, one for char and one for wchar_t. This file is the only
source-file that ever sees the implementation of the class-functions.
The whole stuff is put into a library.

When the class is later used, they can instantiate our class
with whatever type they like (because they have seen our class
declaration), but the linker will only find the explicitly generated
code, causing linker-errors when char or wchar_t was not used.

--
Rune Huseby

I speak for me!
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David A. Cuthbert wrote:

> Out of curiosity, how does a compiler which does not require the
> inclusion of the template code know which templates to generate?

It can know what it needs to generate from the header files.  What it
can't know from just he header files is the code to actually compile.
How does it do that?

It cheats.  If you have the template declaration in header file A.h and
it needs the definition, it automagically looks in A.cpp (or A.cc or A.C
or something similar).  Whether this happens and exactly how is compiler
dependent.

--
Steve R. Karmesin
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
>dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>|>  Out of curiosity, how does a compiler which does not require the
>|>  inclusion of the template code know which templates to generate?
>|>  Using a specific compiler as an example, Borland 4.52 will happily
>|>  *compile* my code, but there will be a link-time error since some
>|>  template code will be missing.

>I'm tempted to say: that's the implementors problem, not yours:-).

Do you think I could use this excuse to explain to my advisor at our
group meetings why I got nothing accomplished in the past week?  :-)

>I don't understand the Borland behavior.  If the compiler knows that
>template instantiation is now or never, why doesn't it generate an error
>immediately, rather than waiting until link time?

Because it can be instantiated by the template source, and the
compiler can't tell this without looking into the object file
generated from the template source.  This introduces an order-
dependency in the compilation and/or some really weird code into the
compiler (I suspect they didn't want/wouldn't have wanted to risk
delaying the shipment of that version while they tested this new
code).  In fact, I've seen code in the template module which contains
code like:

template <class T>  class MyClass { ... };

typedef MyClass<char>  dummyMyClassCharInstantiation;
typedef MyClass<int>  dummyMyClassIntInstantitation;

I hope that they've shifted to the HP or Sun scheme since then.
--
David A. Cuthbert
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

> |>  If your compiler requires that template sources always be included at
> |>  compile time, that would be the exception rather than the rule. The
> |>  draft standard makes no such requirement. Indeed, there has never been
> |>  such a language rule.
>
> Thank you, Steve.  This is what I have been saying for a long time
> (i.e.: that compilers which required explicit inclusion of template
> implementation sources were broken according to the existing rules).
>
> To be fair to the poster, however, I think that the current CD does
> require explicit textual inclusion of templates not declared "export".

That's correct.  The CD does place some restrictions on separate
compilation of templates, and that's one of them.  One of the concerns
is that separate compilation of templates is potentially an expensive
feature; the committee wanted to make sure that programmers don't pay
for that feature unless they use it.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stephen.Clamage@eng.sun.com writes:

|>  sergey@cis.ohio-state.edu (Sergey Zhupanov) writes:
|>
|>  >Ada had separately compiled generics for a long time now, but C++ templates
|>  >seem to always have needed the complete source to be included at compile
|>  >time.  I have heard a lot about "repository" schemes, but the last I heard
|>  >was that they were too hard to implement correctly.
|>
|>  If your compiler requires that template sources always be included at
|>  compile time, that would be the exception rather than the rule. The
|>  draft standard makes no such requirement. Indeed, there has never been
|>  such a language rule.

Thank you, Steve.  This is what I have been saying for a long time
(i.e.: that compilers which required explicit inclusion of template
implementation sources were broken according to the existing rules).

To be fair to the poster, however, I think that the current CD does
require explicit textual inclusion of templates not declared "export".
Or have I misread something once again.  (I'll admit to only having
given the template chapter a quick glance in the last CD.)

|>  Many compilers, including the very first compiler to implement
|>  templates, use repository schemes, and have done so for a long time.
|>
|>  Check with your compiler vendor to see whether a newer version of the
|>  compiler is available that is more convenient to use. If not, consider
|>  changing to a different compiler.

The problem the poster may have is that the requirement for textual
inclusion, while not affecting the majority of compilers, did affect
most, if not all, compilers for certain specific platforms, like
Windows.  So changing to a compiler which doesn't require this might
also require changing platforms, which isn't always an option.

With regards to the initial poster's comments concerning STL, this has
always been a non-issue, even for me.  The standard doesn't even require
that there be header files for the standard libraries, much less that
they include anything resembling an implementation.  For that matter,
for basic class libraries like STL, textual inclusion is actually
acceptable, since they are presumably stable, and available before the
user starts coding.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

My impression had been that most if not all of the PC compilers
require inclusion, as though the templates were macros.  The
Microsoft compiler requires inclusion, and if it's not true
now, it had been true at one time for Borland and Watcom as
well.

Stephen.Clamage@eng.sun.com wrote:
:> sergey@cis.ohio-state.edu (Sergey Zhupanov) writes:
:> >Ada had separately compiled generics for a long time now, but C++ templates
:> >seem to always have needed the complete source to be included at compile
:> >time.  I have heard a lot about "repository" schemes, but the last I heard
:> >was that they were too hard to implement correctly.
:>
:> If your compiler requires that template sources always be included at
:> compile time, that would be the exception rather than the rule. The
:> draft standard makes no such requirement. Indeed, there has never been
:> such a language rule.
:>
:> Many compilers, including the very first compiler to implement
:> templates, use repository schemes, and have done so for a long time.
:>
:> Check with your compiler vendor to see whether a newer version of the
:> compiler is available that is more convenient to use. If not, consider
:> changing to a different compiler.

-- Aaron

---------------------------------
Aaron J Margosis
Work e-mail:  margosis@lccinc.com
Work phone:  703-873-2622 (703-USE-A-MAC ??!!)
Personal:  Aaron_Margosis@compuserve.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

-- Stephen.Clamage@eng.sun.com wrote:

> Many compilers, including the very first compiler to implement
> templates, use repository schemes, and have done so for a long time.

This has truth to it, but I think the term "schemes" really is correct
here, with "scheme" implying tricky, prone to failure and at least
slightly dishonest. [Note: I'm not calling S. Clamage dishonest!  Only
any current repository techniques that claim to be a real implementation
of what the standard specifies.]

What is going on here is that the standard specifies something that is
really quite difficult and a number of compilers do something that
approximates it in simple circumstances but don't do everything.

That is, suppose you have a header file A.h in which you declare the
templated class A that other things will use:

    template<class T> class A { T foo(T); };

and in A.cpp you have

    template<class T> T A<T>::foo(T t) { return t; }

Then in file B.cpp you use A<double> and A<int> and in C.cpp you use
A<int> and A<double*>.

When you compile B.cpp and C.cpp the repository schemes need to do a
couple of things:

1. Find the definition of A<T>::foo.

This is usually done by requiring that if the class declaration is in
A.h the definition must be in A.cpp.  Then it invisibly includes A.cpp
in order to be able to compile foo.  There are various restrictions on
this, mainly that A.cpp can't have any non-template definitions because
when it gets included those look like any other normal declaration and
you get multiply defined symbols.

2. Put the object code somewhere.

The current repository schemes put the object code for A<T>::foo in one
of B.o or C.o.  A<double>::foo would go in B.o, A<double*>::foo would go
in C.o and A<int> would go in one or the other basically randomly.

This lets you compile code for which you have all of A.cpp, B.cpp and
C.cpp available to you at the same time.  This is fine if you're
building applications and writing your own templates but there are
problems with third party software and libraries.

If a third party wants to give or sell you a template library they have
to give you the source code, either in header files like the STL or in
.cpp files that get automagically included.  If they want to keep it
proprietary they could perhaps do some sort of sophisticated shrouding,
but to the best of my knowledge there aren't any commercial packages
that can handle this case yet, and few companies will have the resources
to invent it on their own.

The library problem is that you can't "compile" A.cpp into any sort of
intermediate form, pack that together with the intermediate forms for
A1.cpp, A2.cpp, A3.cpp etc that define other template classes, tell
people to link with it and go on.

The KAI compiler implements an intermediate step that is very useful:
library closure.  That is, if you want to pack B.o and C.o into a
library it will automatically instantiate the things it needs from A.cpp
so that a code that wants to link with B and C doesn't have to know
about A.  They are the first ones that I know of to do this
automatically.

Here is what I would like to be able to do:

"Compile" A.cpp and put the result in some sort of "template library"
A.ta.  I might or might not tell it to instantiate for some types T.
That library would be shrouded about as well as a normal library is.  I
don't care if this is a different type of command from normal
compilation, and I don't care if the format of the template library is
the same as a normal library.

Compile B.cpp and C.cpp to object files.  These don't make any reference
to the template library.  That is kind of important because when you
produce the executable later you might want to link with one of many
versions of the template library.

Link B.o and C.o and A.ta into an executable a.out, doing any necessary
template instantiation.  I would very much like to be able to save the
object code for A<double>::foo, A<int>::foo and A<double*>::foo in a
location like A.ta for later possible use by D.o and C.o, but it is a
little less important to make that really easy because this can be
hacked together using the library closure that KAI implements.

I don't think that I'm just pining for the good old days when a library
was a library and quiche was not to be found. I think that something
like what I've outlined here can be done and the header file/library
model is a powerful one.

It would be very valuable to the C++ community if some agreement could
be found on a good set of semantics for template libraries.  If a
developer could rely on the idea that s/he can produce a library like
this then life would be much simpler.

--
Steve R. Karmesin

Steve R. Karmesin
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
>Stephen.Clamage@eng.sun.com writes:
>|>  If your compiler requires that template sources always be included at
>|>  compile time, that would be the exception rather than the rule. The
>|>  draft standard makes no such requirement. Indeed, there has never been
>|>  such a language rule.
>
>Thank you, Steve.  This is what I have been saying for a long time
>(i.e.: that compilers which required explicit inclusion of template
>implementation sources were broken according to the existing rules).

Out of curiosity, how does a compiler which does not require the
inclusion of the template code know which templates to generate?
Using a specific compiler as an example, Borland 4.52 will happily
*compile* my code, but there will be a link-time error since some
template code will be missing.

The two solutions I can think of involve compiler-redefinitions of
arguments to template functions (see below) or having the linker, upon
finding that some symbols are missing but may be defined in a given
source module, invoke the compiler again for that module.

The complier-redefinition I'm talking about takes a templated function
(or method of a templated class), figures out what information is
required from the templated type, and then rewrites the function call;
for example, consider the following code (which returns a pointer to
the next object in an array):

template <class T>
T*  array<T>::nextPtr(T*  current) {
 // Make sure we're not going to run off the end of the array
 assert(current < last_);

 // Return a pointer to the next object
 return  current + 1;
}

To create a single instantiation of this for any type T, the sizeof(T)
must be known.  Since this is a compile-time constant, it has to be
passed as an argument; so the compiler would actually instantiate a
single version of the above, but as:

char*  array::nextPtr(char*  current, size_t  TSize) {
 assert(current < last_);
 return curent + TSize;
}

Of course, this also assumes that all data/function ptrs can fit in a
char* (I don't know if that is necessarily true).
--
David A. Cuthbert
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Folks,

Ada had separately compiled generics for a long time now, but C++ templates
seem to always have needed the complete source to be included at compile
time.  I have heard a lot about "repository" schemes, but the last I heard
was that they were too hard to implement correctly.

Could someone please shed some light on this, please!  I believe the
success of STL and general wide-spread use of templates is predicated
on having a solution to this problem.


Thanks,
  sergey
----------------------------------
Email: sergey@cis.ohio-state.edu
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

sergey@cis.ohio-state.edu (Sergey Zhupanov) writes:

>Ada had separately compiled generics for a long time now, but C++ templates
>seem to always have needed the complete source to be included at compile
>time.  I have heard a lot about "repository" schemes, but the last I heard
>was that they were too hard to implement correctly.

If your compiler requires that template sources always be included at
compile time, that would be the exception rather than the rule. The
draft standard makes no such requirement. Indeed, there has never been
such a language rule.

Many compilers, including the very first compiler to implement
templates, use repository schemes, and have done so for a long time.

Check with your compiler vendor to see whether a newer version of the
compiler is available that is more convenient to use. If not, consider
changing to a different compiler.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]