This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std random
On Tue, Dec 09, 2008 at 03:17:18PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
> > On Tue, Dec 09, 2008 at 02:29:26PM -0800, Benjamin Kosnik wrote:
> >>> * To do that, I want to avoid depending on the C++0x API/ABI, and
> >>> depend only on the more stable "traditional C++" API/ABI.
> >> Great. Situation normal.
> >>
> >>> But, I
> >>> might still want to use C++0x language features in my application.
> >> This is where you loose me. "Doctor, it hurts when I do this thing."
>
> [For Benjamin]
>
> Why? It's like saying I want to use C99 VLAs, but that I don't want to
> use C99's floating-point library support.
We'd have to make sure that there isn't any funny behavior, or
ABI-incompatible code, caused by compiling the existing library headers
with the compiler in c++0x mode.
> [For Joe]
>
> Independent of the defaults, what do you think about having a way to
> turn off the library support, even if you have the language support? Or
> do we already? What happens with -std=c++0x -U_GLIBCXX_CPP0X?
If that worked, I wouldn't care if it people want to try it, but it creates
something extra to be tested, have bugs, etc.
> > Also, it is certain that the compiler aspects of C++0x (overloading
> > for rvalue references and any other new features like that) are rock
> > stable from an ABI point of view now?
>
> I thin[k] at least some of them are.
It's clear that the library is a much bigger source of ABI risk than
the compiler at this stage, but is there anything in the compiler itself
that also might change in an ABI-incompatible way? I guess the real
question is whether it's worthwhile to implicitly promise more stability
in one area than in the other, by recommending -std=c++0x -U_GLIBCXX_CPP0X
or equivalent.