This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] C++1x breaking the ABI in one more place :(


Ian Lance Taylor wrote:

> If I understand C++0x inline namespaces, it does seem that they could
> be used for that purpose.  It would mean that the new class would have
> a longer mangled name, but so it goes.  But it also seems like C++0x
> inline namespaces have an effect similar to that of the existing GNU
> extension of strong namespaces.  Is there any reason we could not use
> that today to introduce ABI breaking versions of classes?

The problem of making it possible for app1 (old ABI) and app2 (new ABI)
to both use the same libstdc++.so might be solved via inline namespaces.

But the harder problem is the following scenario:

* libstdc++ defines a class C, whose ABI is now changing

* libfoo.so depends on libstdc++.so and uses the old version of C

* main.c creates objects of class C (using the new definition of C) and
passes them to functions in libfoo.so

I don't see how inline namespaces help.  I don't see how anything helps
with that problem -- except the iron discipline not to make an
incompatible change to C.

You can of course have libstdc++ derive from C.  Derived_C (instead of
C) can then be used explicitly in main.c.  That might work in many cases.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]