🚀 go-pugleaf

In article <9510272025.AA09665@absoft.absoft.com>,
"Michael Rice" <mpr@absoft.com> wrote:

|> I have a question concerning class template instantitation, as described
|> in section 14.3.2 on the Sep 1995 WP.  
[snip]
|> The section goes on the give examples of a few cases that do require
|> instantiation and a few that do not require instantiation.  It seems
|> to me, that it should state EXACTLY when they are required and it 
|> doesn't seem to in this section.  Does it anywhere?  If it is not
|> stated implementations could decide anything in a requirement. Couldn't
|> they?

Well, the intent of the committee regarding template classes is that they
should be instantiated precisely when the class types are required to be
complete or when certain ptr to class casts are used.

However, the WP doesn't yet clearly explain when function templates are
required to be instantiated, and the example you gave is certainly a
boundary case -- the return type of a function is not required to be a
complete type until (a) the definition point or (b) the use point. I'd say
that the <long> iterator should _not_ be instantiated but the WP certainly
doesn't make that clear. Perhaps we'll work on it next week in Tokyo.





---
[ 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. ]

>>>>> "MR" == Michael Rice <mpr@absoft.com> writes:
MR> I have a question concerning class template instantitation, as described
MR> in section 14.3.2 on the Sep 1995 WP.  
MR> Paragraph 6 says:
MR> An implementation shall not instantiate a function, nonvirtual member
MR> function, class or member class that does not require instantiation.
MR> The section goes on the give examples of a few cases that do require
MR> instantiation and a few that do not require instantiation.  It seems
MR> to me, that it should state EXACTLY when they are required and it 
MR> doesn't seem to in this section.  Does it anywhere?  If it is not

I believe it is implicit in the semantic descriptions throughout the DWP.
For functions (member or not), they should only be instantiated if they
are called. The only exception are virtual functions: they can be 
instantiated if the class to which they belong is instantiated.

Classes and member classes should be instantiated only if their size
or at least part of their layout is needed. If only their name is needed,
no instantiation should occur.

MR> stated implementations could decide anything in a requirement. Couldn't
MR> they?  Take this example:

MR> struct incomplete;

MR> template<class T>
MR> struct reverse_iterator {
MR>   reverse_iterator ( );
MR>   incomplete i;
MR> };

MR> typedef reverse_iterator<long> reverse_iterator1 ;

MR> template < class T >
MR> struct vector {
MR>   vector ( );
MR> };

MR> main()
MR> {
MR>   vector < int > i ;
MR>   return 0;
MR> }
 
MR> If an implementation decides the typedef above makes the instantiation
MR> of reverse_iterator<long> required this code is ill-formed as the struct
MR> incomplete is incomplete.

MR> On the other hand, the implementation could say it is not required due to
MR> this typedef (which seems correct to me.)  Now the code is well formed?

Indeed, only the ``name'' of the type is needed: that does not require
instantiation. The fact that some compilers (unconformingly) do instantiate
in this case, and that this was a fairly popular method of explicitly
invoking instantiation is somewhat misleading.

MR> What about this:

MR> template<class T>
MR> struct reverse_iterator {
MR>   reverse_iterator ( );
MR> };

MR> typedef reverse_iterator<long> reverse_iterator1 ;

MR> template < class T >
MR> struct vector {
MR>   reverse_iterator1 rbegin ( ) { return reverse_iterator1 ( ) ; }
MR>   vector ( );
MR> };

MR> main()
MR> {
MR>   vector < int > i ;
MR>   return 0;
MR> }

MR> Is reverse_iterator<long> required to be instantiated here even though
MR> the inline function is never called?  
[...]
No, it should not be instantiated (unless it were virtual). Many compilers
are sloppy about this, unfortunately.

	Daveed
---
[ 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. ]

>>>>> David Vandevoorde <vandevod@cs.rpi.edu> writes:

> I believe it is implicit in the semantic descriptions throughout the DWP.
> For functions (member or not), they should only be instantiated if they
> are called. The only exception are virtual functions: they can be 
> instantiated if the class to which they belong is instantiated.

What if their address is taken?  What if they are called in a sizeof
expression?  What about static data members?

Jason
---
[ 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. ]

>>>>> "JM" == Jason Merrill <jason@cygnus.com> writes:
>>>>> David Vandevoorde <vandevod@cs.rpi.edu> writes:
>> I believe it is implicit in the semantic descriptions throughout
>> the DWP.  For functions (member or not), they should only be
>> instantiated if they are called. The only exception are virtual
>> functions: they can be instantiated if the class to which they
>> belong is instantiated.

JM> What if their address is taken?  What if they are called in a
JM> sizeof expression?  What about static data members?

Oops, my apologies. I answered slopilly.
Address taken 
	-> instantiation.
sizeof(expression with function call) 
	-> no instantiation of the function, I think (but e.g. of
	   its return type).

By ``static data members'', were you refering to the elided part
of my post?

	Daveed


[ 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. ]