🚀 go-pugleaf

Robert Pearlman (rp@iscp.bellcore.com) wrote:

> This is required strictly from a practical viewpoint.  The problem is
> simply that changing a header --in any way-- makes every dependent code file 
> recompile.

There is indeed a group of vendors who are talking to each other about
implementing some sort of "release-to-release binary compatibility", which
basically addresses changes like this in the class interface, allowing the
classes to change in certain ways without forcing all client code to
recompile.

This is especially important when releasing class libraries, especially
shared libraries, where the customer may not have an option to rebuild the
application.

Some partial solutions exist today in certain implementations. SGI (I
mention it first because I worked on it :-) has the "dynamic classes"
feature, IBM has SOM, and Taligent also gives you a way to add a virtual
member function to the end of your current list of virtuals (reliably).

The idea of the RRBC group is to come up with a wider, and more
standardized, set of supported changes.

The downside? Code generation for such "RRBC" classes potentially may not
be as optimal as for the current C++ implementations.  Also, there may be
some language restrictions in the use of such classes (like maybe you
cannot have a case label value or an array dimension in a declaration that
is "sizeof class" or "offsetof (class, member) (since the size can
change)).

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]