🚀 go-pugleaf

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.
This decision, IMHO, was responsible for the rapid growth and wide
popularity of C++. Many languages existed in 1985 and exist today which
were and are superior to C++ in many ways (or in every way), yet have only
a relatively small user community and few implementations.

Adding a module system to C++ would make it generally easier to use,
particularly for large projects, but would also make it a different language.
Stroustrup elected not to go that route in designing and developing C++, and
the C++ committee also elected not to go that route.

The committee felt it had more than enough work to do without adding
another huge pile of work. Figuring out a module system, or some subset
that would ease separation of interface and implementation, would take
years of experimentation in addition to all the work that has been done
and is still being done on the standard. For example, the template rules
were published in the ARM in 1990. The rules are still being worked on
as new problems with the definition of templates are discovered.

I'd like to suggest that someone take the time to define and implement
something like a module system for C++. To gain wide acceptance, it should
allow existing C++ source and object code to be integrated into Modular C++
(if I may coin the term) without modification, as well as provide the same C
compatibility as C++ currently has. When you are done, submit it for the next
round of C++ standardization. The timing should be about right.
--
Steve Clamage, stephen.clamage@eng.sun.com