The linker issue does indeed drive the language design here.
How far can one go in the direction of providing an exported
interface that doesn't change when the implementation changes?
Let's look at some options.

    The simplest change is allowing private file-local non-virtual
member functions that don't appear in the class declaration.
These are straightforward to implement - to the compiler,
they're much like static non-class functions.

    This leads to a nice style of programming - one class implementation
per file, no private functions in the class definition.  You can add
new private functions as the implementation grows without
recompiling the clients.  Of course, the private data members are
still in the class definition.

    There's no breaking of encapsulation, as some people have suggested,
because, while you can write functions that access a class's
private members this way, they're unreachable unless a public
member function defined in the class declaration calls them.

    So that's an easy approach to "interfaces".

    Adding data members without recompiling clients
or adding a layer of indirection remains tough to
implement, though.

    John Nagle





David Anderson wrote:

> In article <hxVdc.20581$t_3.15660@newssvr27.news.prodigy.com>,
> John Nagle <nagle@animats.com> wrote:
>
>>  It's worth thinking about how interfaces could work, if
>>we were willing to change the linker.
>>
>>  You'd like, for example, to be able to change the
>>private members of a class without having to recompile
>>the users of the class.  And this should work across
>>DLL/so boundaries.  That's quite feasible.
>>
>>  In fact, it should be possible to add and delete
>>public functions from classes without forcing a
>>recompile of the class users, assuming they're not
>>calling a function no longer present.  Even that
>>should be detected at link time, or DLL/so load time.
>
>
> Perhaps the following is of interest (perhaps not).
>
> Andy Palay spent a couple of years of his life trying to make
> something like this work and SGI shipped "Delta C++" with this
> sort of capability in the early 90's.  But with the added
> capability of adding/moving data members.
>
> It was way complicated.  It made-inapplicable much optimization
> technology, so performance of the code was, of necessity, worse
> than normal C++.  It affected the compiler, static-linker, and
> even the run-time-linker in very complicated ways.  It was very
> difficult to design a set of capabilities in a way that was
> actually useful.  And even harder to actually implement.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@logicacmg.com (Michiel Salters) wrote in message news:<fcaee77e.0404130652.1b14b102@posting.google.com>...

> It's rather unrelated to the preprocessor, but impossible because of
> fundamental C rules: "For any complete POD object type T, whether or
> not the object holds a valid value of type T, the underlying bytes (1.7)
> making up the object can be copied into an array of char or unsigned char.
> If the content of the array of char or unsigned char is copied back into
> the object, the object shall subsequently hold its original value."
>
> To enable the no-recompile mechanism, sizeof(X) may not change if X gets
> another private member, yet it must hold more unsigned chars.

If X gets another private member, then X was not a POD object type T,
so the above does not apply.

Mark Williams

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) writes:
[snip]
>   I'd argue that the implementors should suffer more for the
> benefit of the users of the language.  There really aren't that
> many C++ compiler developers, after all.
[snip]

The standard was finalized in 1998. Yet for years after many
    implementations contained numerous gross violations. Even now,
    only one frontend (EDG) claims a complete implementation of the
    core language, and only one library (dinkum) claims a complete
    implementation of the library.

It is fallacious to believe only implementors suffer from
    implementation difficulties.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kmarkw65@yahoo.com (Mark Williams) wrote in message news:<7adff5d1.0404140502.114b3386@posting.google.com>...
> Michiel.Salters@logicacmg.com (Michiel Salters) wrote in message news:<fcaee77e.0404130652.1b14b102@posting.google.com>...
>
> > It's rather unrelated to the preprocessor, but impossible because of
> > fundamental C rules: "For any complete POD object type T, whether or
> > not the object holds a valid value of type T, the underlying bytes (1.7)
> > making up the object can be copied into an array of char or unsigned char.
> > If the content of the array of char or unsigned char is copied back into
> > the object, the object shall subsequently hold its original value."
> >
> > To enable the no-recompile mechanism, sizeof(X) may not change if X gets
> > another private member, yet it must hold more unsigned chars.
>
> If X gets another private member, then X was not a POD object type T,
> so the above does not apply.
>
> Mark Williams

Incorrect assumption.
[quote 9/4]
A POD-struct is an aggregate class that has no non-static data members of
type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator and
no user-defined destructor.
[/quote]

Private doesn't preclude POD-ness.

Even if it did, the assumption would be that sizeof(X) doesn't change if
the first private member is added to a POD, yet the information needed
to store the location of that member would require at least a pointer
in that object, which wasn't there before. Hence, sizeof(X) would change
by sizeof(void*) or so.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

   It's worth thinking about how interfaces could work, if
we were willing to change the linker.

   You'd like, for example, to be able to change the
private members of a class without having to recompile
the users of the class.  And this should work across
DLL/so boundaries.  That's quite feasible.

   In fact, it should be possible to add and delete
public functions from classes without forcing a
recompile of the class users, assuming they're not
calling a function no longer present.  Even that
should be detected at link time, or DLL/so load time.

   That would seem to be the correct goal here.
It would simplify library management no end.

   John Nagle
   Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <hxVdc.20581$t_3.15660@newssvr27.news.prodigy.com>,
John Nagle <nagle@animats.com> wrote:
>   It's worth thinking about how interfaces could work, if
>we were willing to change the linker.
>
>   You'd like, for example, to be able to change the
>private members of a class without having to recompile
>the users of the class.  And this should work across
>DLL/so boundaries.  That's quite feasible.
>
>   In fact, it should be possible to add and delete
>public functions from classes without forcing a
>recompile of the class users, assuming they're not
>calling a function no longer present.  Even that
>should be detected at link time, or DLL/so load time.

Perhaps the following is of interest (perhaps not).

Andy Palay spent a couple of years of his life trying to make
something like this work and SGI shipped "Delta C++" with this
sort of capability in the early 90's.  But with the added
capability of adding/moving data members.

It was way complicated.  It made-inapplicable much optimization
technology, so performance of the code was, of necessity, worse
than normal C++.  It affected the compiler, static-linker, and
even the run-time-linker in very complicated ways.  It was very
difficult to design a set of capabilities in a way that was
actually useful.  And even harder to actually implement.

It worked but it failed.  In the end nobody wanted it.

On the other hand, maybe you can do it right.
I wish you well at it...

But will what-is-doable actually satisfy a real need?

Regards,
David B. Anderson davea at sgi dot com http://reality.sgiweb.org/davea
[Not an official postion of sgi... ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>    It's worth thinking about how interfaces could work, if
> we were willing to change the linker.
>
>    You'd like, for example, to be able to change the
> private members of a class without having to recompile
> the users of the class.  And this should work across
> DLL/so boundaries.  That's quite feasible.
>
>    In fact, it should be possible to add and delete
> public functions from classes without forcing a
> recompile of the class users, assuming they're not
> calling a function no longer present.  Even that
> should be detected at link time, or DLL/so load time.
>
>    That would seem to be the correct goal here.
> It would simplify library management no end.

If I'm not mistaken this entire area comes under the murky heading of Cpp
and 'implementation defined'.  My personal inclination is this entire area
is in need of (re-)examination and (re-)definition.  The danger in doing
that is the potential for breaking many programs and development tools
which are idiosyncratically dependent on the current loose definitions.

I understand the linker and preprocessor are not the same animal.
Nonetheless, they both seem to fall into the illdefined category of
C++/system interface.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

  To some extent, that's true.  There are many things
in C++ that are there to support the traditional linking model,
so it does have standards impact.

  For example, the C++ rules for order of static initialization
are carefully crafted to make it easy for dumb linkers to ignore
the problem.  This places the burden on "the user" to somehow
get order of initialization right.  Compare Modula II/III, where
the linker is required to perform a dependency sort on static
initializations and detect loops.  It would be easy to write
a rule in the standard that static objects must be initialized
in an order that prevents access to an unconstructed object.
But implementors would scream.

  I'd argue that the implementors should suffer more for the
benefit of the users of the language.  There really aren't that
many C++ compiler developers, after all.

    John Nagle


Steven T. Hatton wrote:

> John Nagle wrote:
>
>
>>   It's worth thinking about how interfaces could work, if
>>we were willing to change the linker.
>>
>>   You'd like, for example, to be able to change the
>>private members of a class without having to recompile
>>the users of the class.  And this should work across
>>DLL/so boundaries.  That's quite feasible.
>>
>>   In fact, it should be possible to add and delete
>>public functions from classes without forcing a
>>recompile of the class users, assuming they're not
>>calling a function no longer present.  Even that
>>should be detected at link time, or DLL/so load time.
>>
>>   That would seem to be the correct goal here.
>>It would simplify library management no end.
>
>
> If I'm not mistaken this entire area comes under the murky heading of Cpp
> and 'implementation defined'.  My personal inclination is this entire area
> is in need of (re-)examination and (re-)definition.  The danger in doing
> that is the potential for breaking many programs and development tools
> which are idiosyncratically dependent on the current loose definitions.
>
> I understand the linker and preprocessor are not the same animal.
> Nonetheless, they both seem to fall into the illdefined category of
> C++/system interface.
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<jvWdnY6ola-9f-fdRVn-hg@speakeasy.net>...
> John Nagle wrote:
>
> >    It's worth thinking about how interfaces could work, if
> > we were willing to change the linker.
> >
> >    You'd like, for example, to be able to change the
> > private members of a class without having to recompile
> > the users of the class.  And this should work across
> > DLL/so boundaries.  That's quite feasible.
> >
> >    In fact, it should be possible to add and delete
> > public functions from classes without forcing a
> > recompile of the class users, assuming they're not
> > calling a function no longer present.  Even that
> > should be detected at link time, or DLL/so load time.
> >
> >    That would seem to be the correct goal here.
> > It would simplify library management no end.
>
> If I'm not mistaken this entire area comes under the murky heading of Cpp
> and 'implementation defined'.  My personal inclination is this entire area
> is in need of (re-)examination and (re-)definition.  The danger in doing
> that is the potential for breaking many programs and development tools
> which are idiosyncratically dependent on the current loose definitions.

It's rather unrelated to the preprocessor, but impossible because of
fundamental C rules: "For any complete POD object type T, whether or
not the object holds a valid value of type T, the underlying bytes (1.7)
making up the object can be copied into an array of char or unsigned char.
If the content of the array of char or unsigned char is copied back into
the object, the object shall subsequently hold its original value."

To enable the no-recompile mechanism, sizeof(X) may not change if X gets
another private member, yet it must hold more unsigned chars.

Regards,
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]