🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

3 total messages Started by Michael Rice Mon, 30 Oct 1995 18:05
Re: Template Instantiation
#2363
Author: Michael Rice
Date: Mon, 30 Oct 1995 18:05
47 lines
2200 bytes
> 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.
> 

What about the use of a typedef name from the class.  No size or layout
is needed.   Example:

struct incomplete;

template <class T>
struct allocator {
public :
  typedef T* pointer;
  incomplete i;
};

template <class T>
struct vector {
  allocator<T>::pointer start;
  vector();
};

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

Then this should be well-formed.  While specializing vector<int> we have
to determine the member start's type.  We don't need to specialize 
allocator<int> to do that.  So we can use allocator<int>::pointer, and
allocator<anything>::pointer without ever specializing the class.  Is that
the intent?  Is that desirable?

-- 
Mike Rice                                                   Absoft Corporation
mpr@absoft.com                                                  (810) 853-0050

[ 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. ]
Re: Template Instantiation
#2370
Author: David Vandevoorde
Date: Tue, 31 Oct 1995 02:45
22 lines
1522 bytes
>>>>> "MR" == Michael Rice <mpr@absoft.com> writes:
I (Daveed) wrote:
>> 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> What about the use of a typedef name from the class.  No size or
MR> layout is needed.  Example:
[example elided ...]

Good point. I thought it shouldn't (necessarily) require instantiation
of the typedef-enclosing class, but my favo(u)rite compiler says
otherwise (with your particular example)... and its designers are very 
knowledgeable in this area.

Anyone care to comment?

	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. ]
Re: Template Instantiation
#2366
Author: Sean A Corfield
Date: Tue, 31 Oct 1995 17:49
34 lines
1796 bytes
In article <VANDEVOD.95Oct30181524@avs.cs.rpi.edu>,
vandevod@cs.rpi.edu (David Vandevoorde) wrote:

|> MR> What about the use of a typedef name from the class.  No size or
|> MR> layout is needed.  Example:
|> [example elided ...]
|> 
|> Good point. I thought it shouldn't (necessarily) require instantiation
|> of the typedef-enclosing class, but my favo(u)rite compiler says
|> otherwise (with your particular example)... and its designers are very 
|> knowledgeable in this area.
|> 
|> Anyone care to comment?

I'd go with your compiler designers on this one: to get the type of a class
member, you'd have to instantiate the class. There's a paper being written
on this topic (when types are required to be complete) which should be
voted on in March '96. Classes are required to be instantiated exactly when
the class type is required to be complete (plus a couple of other, explicit
uses such as in pointer to class casts). If the WP isn't clear enough on
this, well, we're still working on it!



--
         You must be out of your brilliant mind - Furniture
                 http://uptown.turnpike.net/~scorf


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

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads