In article <rfgCttpup.3DE@netcom.com>, rfg@netcom.com (Ronald F.
Guilmette) says:
>
>In article <1994Jul29.055618.15181@qds.com> plindsay@qds.com (Phillip A.
Lindsay) writes:
>>Will there be a portable way to control template
>>instantiation?  This becomes especially important
>>when you want to ensure only one instantiation of
>>a template lives in a particular shared library.
>>It gets nasty when you talk about templates which
>>contain/inherit other templates. If someone wants
>>the contained/inherited template to live in a
>>different shared library than the dependent
>>template...Good luck.  Right now, we have code that
>>is very compiler specific...the only way
>>we acheive portability is by spending
>>significant time modifying source to adhere to
>>a different compiler implementation....It has
>>to be better than this...
>
>What makes you think so?
>

(btw, I am not asking purists to accept shared libraries as a language
construct!)

Because, as it stands now, portability can only be achieved if C++
source code understands *every* compiler implementation. Shouldn't
some group define something to ensure better portability? Isn't that
one of the founding reasons for the C++ standard?
We have battled with four different compiler implementations on three
different platforms for almost two years now, it isn't getting better.
Every compiler vendor solves the problem differently and it adversly
affects the structure of subsystems/modules.

>The particular aspect of C++ implementation that you are concerned about
>is outside the scope of what the C++ standardization commitee is trying
>to standardize.  Thus, if you really want a standard for template
instantia-
>tion control (which takes into account shared libraries) then you'll
have
>to get it from some orginazation OTHER THAN the C++ standardization
committee.
>

Well why?  I have had the discussion about "appreciating the bounds of
the charter..." The charter cannot ignore the fact that as more complex
systems are built with C++, the issue of template instantiation and
shared libraries will become paramount.  Do we want compiler specific
#pragma's to pollute millions of lines of source code? To brush it aside
is to ignore the fact that many new systems are built around shared
libraries (or DLLs) today.

>(The situation is not unlike that of automobile fule tanks.  There is no
>single ``standard'' size for automobile fule tanks... sizes vary from
>manufacturer to manfacturer, and also from model to model for each
>manufacturer.  If it is really important to you, for whatever reasons,
>to have a lot of cars which all have the same size fuel tanks, then you
>had better just buy your cars from one manufacturer, and have them all
be
>the exact same model.)
>

I wish I could see how this analogy relates...

Phillip A. Lindsay                    All opinions expressed are
Quantitative Data Systems, Inc.       my own and do not reflect
9500 Toldeo Way, Irvine,Ca 92718-1806 the opinion of my employer.
Ph. 714-588-5144 / Fax 714-588-5181   EMAIL: plindsay@qds.com

In article <1994Jul29.055618.15181@qds.com> plindsay@qds.com (Phillip A. Lindsay) writes:
>Will there be a portable way to control template
>instantiation?  This becomes especially important
>when you want to ensure only one instantiation of
>a template lives in a particular shared library.
>It gets nasty when you talk about templates which
>contain/inherit other templates. If someone wants
>the contained/inherited template to live in a
>different shared library than the dependent
>template...Good luck.  Right now, we have code that
>is very compiler specific...the only way
>we acheive portability is by spending
>significant time modifying source to adhere to
>a different compiler implementation....It has
>to be better than this...

What makes you think so?

The particular aspect of C++ implementation that you are concerned about
is outside the scope of what the C++ standardization commitee is trying
to standardize.  Thus, if you really want a standard for template instantia-
tion control (which takes into account shared libraries) then you'll have
to get it from some orginazation OTHER THAN the C++ standardization committee.

(The situation is not unlike that of automobile fule tanks.  There is no
single ``standard'' size for automobile fule tanks... sizes vary from
manufacturer to manfacturer, and also from model to model for each
manufacturer.  If it is really important to you, for whatever reasons,
to have a lot of cars which all have the same size fuel tanks, then you
had better just buy your cars from one manufacturer, and have them all be
the exact same model.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CtrGEK.600@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:
|> In article <1994Jul29.055618.15181@qds.com> plindsay@qds.com (Phillip A. Lindsay) writes:
|> >Will there be a portable way to control template
|> >instantiation?
|>
|>  template type<int>; // instantiate class "type" with int _here_.
|>

How much of the class does this instantiate?  All member functions?
Just those that have references to them?  Does it instantiate the
class into the current object module?  How do you get the object code
into a library with complete closure so that clients of the library
won't re-instantiate code?


Andrew Werth
ajw1@cc.bellcore.com

>>>>> Andrew Werth <ajw1@cc.bellcore.com> writes:

> How much of the class does this instantiate?  All member functions?

Yes.

> Does it instantiate the class into the current object module?

Unspecified.  It may go into the current object module or into some
repository structure or nowhere.

> How do you get the object code into a library with complete closure so
> that clients of the library won't re-instantiate code?

Unspecified.  This is really a quality of implementation issue; all the WP
says is that a template shall not be explicitly instantiated more than
once, and no diagnostic is required for that rule -- D&E even encourages
implementations to disregard it.  So the explicit instantiation syntax is
little more than a hint to the compiler.

Personally, I feel that the right way to implement explicit instantiation
is for it to instantiate into the current object module, so that libraries
can be made.  So that's the way g++ does it.  Other vendors may feel
differently.

Jason

Will there be a portable way to control template
instantiation?  This becomes especially important
when you want to ensure only one instantiation of
a template lives in a particular shared library.
It gets nasty when you talk about templates which
contain/inherit other templates. If someone wants
the contained/inherited template to live in a
different shared library than the dependent
template...Good luck.  Right now, we have code that
is very compiler specific...the only way
we acheive portability is by spending
significant time modifying source to adhere to
a different compiler implementation....It has
to be better than this...
Phil (plindsay@qds.com)

In article <1994Jul29.055618.15181@qds.com> plindsay@qds.com (Phillip A. Lindsay) writes:
>Will there be a portable way to control template
>instantiation?

 template type<int>; // instantiate class "type" with int _here_.



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189