🚀 go-pugleaf

In article <4a4io5$s0v@cronkite.seas.gwu.edu> bkeefe@seas.gwu.edu
(Brian J. Keefe) writes:

|> The online MSVC4 manual says to use syntax like:

|> template Stack<int,6>;

|> to force class template instantiation for all operations.
|> I did not find this in the ARM. Is it ANSI compliant?

No.  The standard offers no means of forcing template instantiation,
probably because forcing instantiation has no utility.

If you use the template, it is instantiated.  You don't need to force
instantiation.  If you don't use it, why do you want to instantiate
it?  Just to have extra code (which is never called) in your
application.

Note that in most modern implementations, if you use a template in a
library, the implementation will instantiate the template and include
the code of the instantiation in the library automatically.
(Historically, with older link-time instantiation compilers, like
CFront, you had to do this manually.  But while I was very happy to
have CFront back then, it is hardly what I would call state of the art
today.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9512071347.AA29456@lts.sel.alcatel.de>, James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
> If you use the template, it is instantiated.  You don't need to force
> instantiation.  If you don't use it, why do you want to instantiate
> it?  Just to have extra code (which is never called) in your
> application.

To me, the issue would not be instantiating a template that is never used,
but rather to control exactly *where* and *when* the instantiation occurs.
For reasons of building shared libraries, or even unshared libraries that
are going to be used by multiple programs, one may wish to know exactly in
what object module a given template instantiation is placed.

Along with a mechanism for explicit instantiation, I would also want a way
to tell the compiler to *never* instantiate automatically.  One of the
scary things about the current template mechanism is that I can
accidentally instantiate a template and I'll never know it, except where it
causes my program to break.  I'd much rather explicitly instantiate
everything, then I know that any accidents will show up as link-time
errors.

Another justification for this is controlling the compile-time options when
an instantiation is compiled.  I may decide that a particular template
needs more (or less) optimization.  Many modern compilers have tons of
options for controlling optimization that, for best performance, have to be
tuned.  They also have lots of options that affect compile time that could
make the difference between hours of compilation or seconds.  (A colleague
of mine just implemented a new compiler option that made a rather bizarre
machine-generated program go from 17 hours of compile time to 1 minute!)

Other compilation options are also important.  Some systems require special
code generation techniques if a module is going to reside in a shared
library.  How do I get that to happen, especially if the code that uses the
template is *not* destined for a shared library?

How do I know what options were used to compile an instantiation if I don't
even know when it will be compiled?

I could go on, but I think you get the idea.

Some compilers now existing have options and/or pragmas for doing this.
The question is whether that's sufficient or whether some or all of it
should be standardized.  I don't honestly know -- I just wanted to give a
user's view of why this feature is desirable.

-- 
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
There's something wrong with an industry in which amazement is a common
reaction to things going right.

"Hard work never scared me.  Oh, sure, it has startled me from a distance."
                                                       -- Professor Fishhawk
------------------------------------------------------------------------------

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9512071347.AA29456@lts.sel.alcatel.de> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

   No.  The standard offers no means of forcing template instantiation,
   probably because forcing instantiation has no utility.

What about 14.4 (April DWP):

  14.4  Explicit instantiation                           [temp.explicit]

1 A class or function specialization can be explicitly instantiated from
  its template.

2 The syntax for explicit instantiation is:
          explicit-instantiation:
                  template declaration
  Where the unqualifier-id in the declaration shall  be  a  template-id.
  [Example:
          template class Array<char>;

          template void sort<char>(Array<char>&);
   --end example]

[etc]

Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``Efforts to maintain the "purity" of a language only succeed in establishing an
  elite class of people who know the shibboleths.  Ordinary folks know better, 
  even if they don't know what "shibboleth" means.'' - Larry Wall

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9512071347.AA29456@lts.sel.alcatel.de>, James Kanze US/ESC
60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

> In article <4a4io5$s0v@cronkite.seas.gwu.edu> bkeefe@seas.gwu.edu
> (Brian J. Keefe) writes:
> 
> |> The online MSVC4 manual says to use syntax like:
> 
> |> template Stack<int,6>;
> 
> |> to force class template instantiation for all operations.
> |> I did not find this in the ARM. Is it ANSI compliant?
> 
> No.  The standard offers no means of forcing template instantiation,
> probably because forcing instantiation has no utility.

 [snip]

 Section 14.4 of the draft standard documents explicit template
instantiation: the syntax is "template class Stack<int, 6>;". BTW I know
of two uses for explicit instantiation:

1) It forces every function defined in the template class to be
instantiated. This means that each function is actually compiled: you
don't have to worry about some stupid syntax error in functions that
haven't been used.

2) More importantly there are times when you want to control where the
code is generated. For example, programs that have to run on low end Macs
often segment the code so it doesn't all have to be in memory at once. In
this sort of situation it's very nice to be able to control where the
commonly used template classes go.

  --Jesse


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]