On Wed, 2005-05-25 at 10:37 +0200, Paolo Carlini wrote:
> >>Why?  To be honest, I keep harping on this mostly because I think it
> >>should happen.  All the C++-in-GCC noise is a digression.  
> [.....]
> In practice, we have got an handful of bugs unfixable within the
> current
> ABI (mostly already fixed in v7) and a major QoI issue (ref-counted
> string vs MT) which certainly we don't want in anything
> "definitive" (x).

The real problem I think is not really casting an ABI in stone, but
merely to have "some stability" over time. Maybe the only thing that is
missing is a "commitment" of the C++ library ABI stable over a few (two,
three ?) major gcc releases as there is one for the core compiler (and
remember it took several releases to achieve it)...

I agree that fixing the ABI for good is probably several years away, but
user expectation of keeping some stability is also reasonable...
I also believe making "some committment" (note that I clearly avoid to
state which one and I really understand that already people try to make
as little breakage as possible) helps to achieve the goal. So pushing up
for a stable ABI is also a good thing.

All that being said, I do not know why this C++ transition should be
blocked by libstdc++ ABI stability. Given the history the GCC project
and the amount of work (and the expected benefits) that would arise just
from converting to a simple subset of C++ (class,some simple inheritance
and maybe simple templates and no library stuff), I would argue that a
lot of benefit could be gained already just with core C++ (ie without
the library).

And this limits the ABI breakage problem to libsupc++ for which (as I as
I know) the problem is much simpler (at least it seems feasible to my
unexperienced observer)....

Obviously, using the C++ library could bring some more benefits, but
this seems clearly a second stage which could be done once the stdc++
library will freeze its ABI.

SO THE QUESTION IS: is libsupc++ is a state for which its ABI can be
freezed easily (I have not followed the topic closely enought to really
know, but it really seems to me that the answer is yes).

That being said, and to go back to the topic of freezing the libstdc++
ABI, maybe part of this work can be done immediately in the sense that
if there are parts of the library (eg list or vector) that are simple
enough and in a good state, then maybe it is possible to freeze those
(eventually providing a library in two pieces one stable and one
unstable), without freezing the whole ABI. Then immediately this part of
the standard C++ library becomes usable per Zack's request...

But obviously this C++ transition is plain science fiction for now...
Still science fiction sometimes brings useful ideas so it needs to be
considered. And actually, some science fiction creeps out of books much
faster than expected, so I'm still hoping....

Reply via email to