Re: std::call_once without TLS

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/5/4 Chris Fairles :
>
> Nothing further about this specific issue. The proposed solution in
> 39909 is fine.

Thanks, Chris.

> On a side note, I misunderstood that "experimental" features can only
> change semantically between releases, and that binary compatibility of
> those features is still guaranteed (even though semantic changes
> probably give rise to more elusive errors than those caused by ABI
> breakages). I hope we don't run into this again, like the std
> committee deciding to rename something in the public API that we've
> already exported as part of the 3.4.11 ABI.

One "solution" would be to provide useless stubs that make linking
succeed, but with no functionality.  In the call_once case I'm glad
Paolo made me take another look at it, as I think the final
ABI-compatible fix is much better than my first attempt - it
retroactively fixes (some) old code that wouldn't work before.

Personally I agree that a hard failure from the linker might be
preferable, but hopefully it won't cause big problems either way, as I
doubt many people are using the C++0x mode in production code.

At some point the ABI will change, and then we get all sorts of cool
things like Paolo's vstring to make up for it  :-)   If that ABI
change coincides with the C++0x features becoming non-experimental
then it won't really matter if the features had been slightly hampered
by maintaining backward compatibility up to that point.

Real Soon Now I'm going to post a prototype <future> implementation
for comments, so hopefully any problems can be found before it ships
in a release and the ABI gets frozen.

Jonathan