🚀 go-pugleaf

In article <405boq$4br@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve  
Clamage) writes:

[snip]

> The difference is that in order to instantiate a class, you
> do not need to know anything about the contents of its member functions.
> You DO need to know everything about the types of its members, however.
> Thus, members of a class may not have incomplete types.

IMHO this is one of the major drawbacks of the language as currently  
defined. Having to textually list *all* the members of a class, including  
the private ones, before the place an object of that class is instantiated  
makes it hard to have a clean separation between interface and  
implementation. We either have to live with the extra dependencies of the  
user code on the private class members or declare a separate 'physical  
representation' class whose instances are usually allocated on the heap,  
which slows down the program.

For quite a few cases, it can be shown that a mechanism can be implemented  
that would allow for the instantiation of objects whose full definition  
has not yet been seen by the compiler, for instance because it is in a  
different translation unit.

Has the committee considered any extensions to the current language  
definition that would allow for such a mechanism? If so, why don't they  
appear in the draft standard? If not so, why not?

- Wil