In article <2q85qa$638@usenet.INS.CWRU.Edu>, ej070@cleveland.Freenet.Edu (Ron Rossbach) writes:
|>
|> The real problem (IMHO) is requiring C++ programs which use
|> a particular class to #include the complete (including privates)
|> declaration of the class.  As mentioned before, other languages
|> like Ada get this right; a user should only need to #include the
|> public interface.
|>
|> I realize this creates problems for object sizing, but they are
|> fixable, I would think.

I think the FAQ question 71 should be updated on this one.
A good way to separate interface from implementation, is to only
put public and protected memberfns and variables in your class, and then
put all the private stuff in another class which your class privately
inherits.

******************************************************************************
Terje Braaten                            |   "For God sent not his Son into
The Norwegian Institute of Technology  --+--  the world to condemn the world;
Faculty of Physics and Mathematics       |    but that the world through him
E-mail: terjebr@kari.fm.unit.no          |    might be saved" John 3:17
******************************************************************************

terjebr@stud.unit.no (Terje Br}ten) writes:

>In article <2q85qa$638@usenet.INS.CWRU.Edu>, ej070@cleveland.Freenet.Edu (Ron Rossbach) writes:
>|> I realize this creates problems for object sizing, but they are
>|> fixable, I would think.

>I think the FAQ question 71 should be updated on this one.
>A good way to separate interface from implementation, is to only
>put public and protected memberfns and variables in your class, and then
>put all the private stuff in another class which your class privately
>inherits.
What does this solve? The base class must be known in its size as well,
and so must be included in the source as well in some form or other.

And if you put in in a separate include file, just including the private
definitions, or a private base class will not make much of a difference.

The only method to have private bases to a class which do not need to
be fully specified is not to derive from a class, or to include
a class, but to include a *pointer* to the private data.
And that not only counterfeits the whole inheritance idea, but is
also less efficient and contrary to the whole C++ class idea which
does rate minor performance problems as more important as abstraction
methods which extend *over* the source order paradigm.

That is, C++ classes are capsulated only in one respect:
you can very well separate your different source concepts into different
source files.

You cannot, however, capsulate to such a degree as to comfortably
make, say, "binary only" libraries available. You cannot replace
an underlying mechanism (say B-trees instead of linked lists)
by replacing just a library in object format without recompiling
with new header files, *unless* you have made a base class with
a lot of virtual functions which the library users will access,
and which the library itself will inherit from.

However, you have to *design* for such things, and of course
a small penalty in time is implied.

But mostly C++ is aimed to provide (for method changes) only
the guarantee, that you need not *change* the rest of your
source, not that you need not *recompile* it.

If the latter would have been a major design goal, C++ classes would
have looked different, and probably a bit more like that of
other OOP languages.

Note that you *can* achieve the functionality by inheriting from
a stub access class with lots of virtuality, but you need to do it
yourself, so it is not a C++ language concept, just like inheritance,
virtual functions, base classes etc. can be done in C, but you
have to do it yourself, and so most probably won't unless forced to.

As a result, average C programs are *not* very object oriented,
and average C++ programs will *not* change mechanisms without
recompilation. It is not as much a question of what you *can*
do with the language, but which the language *forces* you
to do, or at least very strongly suggests.
--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

I am sorry, I made a mistake.

I thought a simple forward declaration would solve the problem, like in:

   class myclass_private;

   class myclass: myclass_private {
   public:
     // whatever
   }

But I know now that it won't compile, since the compiler needs a full
definition of myclass_private in order to inherit from it.
I think that it is stupid, but anyway, it is not I who have constructed
the C++ language. (May be it's better of that way anyway :).

******************************************************************************
Terje Braaten                            |   "For God sent not his Son into
The Norwegian Institute of Technology  --+--  the world to condemn the world;
Faculty of Physics and Mathematics       |    but that the world through him
E-mail: terjebr@kari.fm.unit.no          |    might be saved" John 3:17
******************************************************************************