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....
