🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 1427@ittpub, wil@ittpub.nl (Wil Evers) writes:
: >
: >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.

: All true.

: >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.

: In fact, other languages are defined that way, so this is not just a
: theorectical observation. Ada, Turbo Pascal, and Modula-2 are examples.

: >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?

: The original intention of C++ was to use the C compilation model, and to
: allow as much compatibility with C source and object code as possible.


By way of terminology, let's say that a type "depends" on the types of
its members, bases, and elements.  It requires two passes to
topologically sort the graph of this dependency relation:

  First pass:   attach to each node its in-degree and put the nodes
                of in-degree zero into a special set;

  Second pass:  while ( the graph has nodes of in-degree zero ) {
                   remove one from the graph;
                   update the in-degrees of its neighbors;
                   add to the set the neighbors with in-degree zero;
                }

A compiler can process type definitions in order of removal.  There
will be no left-over nodes if (and only if) dependency is well
founded, i.e. its graph is acyclic.
                
The current C++ requirement, that type definitions be completed before
being used to declare members, essentially requires the programmer to
topologically sort the source files, work that a compiler can and
should do for itself.  There would be no issues of backward
compatibility (with C or with earlier versions of C++) and no required
changes to linkers or header files, if this requirement were relaxed to
simply requiring that dependency be well founded.


Tom Payne (thp@cs.ucr.edu)