RFA: v3 PATCH to add on_quick_exit/quick_exit to std

On 02/12/2013 12:40 PM, dominiq@lps.ens.fr wrote:
> IIRC I have already asked a similar question about atan2, erf, ...
> which don't appear in the std namespace on darwin.
You should check whether darwin by chance uses by default c_std instead 
of c_global. The former doesn't provide C++11 facilities. If, on the 
other hand, it uses c_global, it means _GLIBCXX_USE_C99_MATH_TR1 is 
undefined because a configure test fails on that specific darwin release 
you are using. But the last time I checked, modern darwin defined 
_GLIBCXX_USE_C99_MATH_TR1, no problems.

Anyway, about the cstdlib issue the below makes available the new 
functions in c_std/cstdlib too, and I'm going to commit it, it's close 
to what Jason originally committed. But, as I said already we don't 
normally provide C++11 functions in c_std, Benjamin may want to review 
what we are doing in c_std vs c_global, he designed the split.

Paolo.

//////

> But the last time I checked, modern darwin defined
> _GLIBCXX_USE_C99_MATH_TR1, no problems.

AFAICT this is true, but I think darwin10 was released in 2011
so I doubt it has any support for c++11.

> Anyway, about the cstdlib issue the below makes available the new 
> functions in c_std/cstdlib too, and I'm going to commit it, it's close
> to what Jason originally committed. ...

It works, thanks,

Dominique

PS any chance to use this machinery for other missing items:
hypot, erf, ..., i.e., the c++11 additions?

On 02/12/2013 01:47 PM, dominiq@lps.ens.fr wrote:
>> But the last time I checked, modern darwin defined
>> _GLIBCXX_USE_C99_MATH_TR1, no problems.
> AFAICT this is true, but I think darwin10 was released in 2011
> so I doubt it has any support for c++11.
>
>> Anyway, about the cstdlib issue the below makes available the new
>> functions in c_std/cstdlib too, and I'm going to commit it, it's close
>> to what Jason originally committed. ...
> It works, thanks,
Good, thus looks like you are using c_std on your machine?!? Because I 
just tried, and on a Darwin 12.2.0 machine the build uses c_global by 
default and everything was fine even before my last patchlet 
(_GLIBCXX_USE_C99_MATH_TR1 defined of course).

I think current Darwin is already fine, in general, in these areas.

Again, the current status is in a sense good because when the
_GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined, 
thus the system has the functions in its c library, including <cstdlib> 
makes available the functions in namespace std irrespective of the 
configury. But then why having c_std in the first place? I'll leave this 
to Benjamin...

Paolo.

On 02/12/2013 07:55 AM, Paolo Carlini wrote:
> Again, the current status is in a sense good because when the
> _GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined,
> thus the system has the functions in its c library, including <cstdlib>
> makes available the functions in namespace std irrespective of the
> configury. But then why having c_std in the first place? I'll leave this
> to Benjamin...

As I understand it, the difference between c_std and c_global is 
supposed to be that c_std keeps the C library in std, whereas c_global 
has it in both std and the global namespace.  All the other differences 
that have arisen between them seem unintended and wrong.

There is, however, a question whether we need c_std at all now that the 
standard allows the C library to be in the global namespace as well.

Jason

Hi,

On 02/13/2013 03:38 PM, Jason Merrill wrote:
> On 02/12/2013 07:55 AM, Paolo Carlini wrote:
>> Again, the current status is in a sense good because when the
>> _GLIBCXX_HAVE_AT_QUICK_EXIT and _GLIBCXX_HAVE_QUICK_EXIT are defined,
>> thus the system has the functions in its c library, including <cstdlib>
>> makes available the functions in namespace std irrespective of the
>> configury. But then why having c_std in the first place? I'll leave this
>> to Benjamin...
> As I understand it, the difference between c_std and c_global is 
> supposed to be that c_std keeps the C library in std, whereas c_global 
> has it in both std and the global namespace.  All the other 
> differences that have arisen between them seem unintended and wrong.
The fact is, for many, many years we didn't even try to keep the C 
library in std only. On the other hand the split c_std / c_global is 
relatively recent (was born in 4.3). Yes, I'm quite confused ;)
> There is, however, a question whether we need c_std at all now that 
> the standard allows the C library to be in the global namespace as well.
Indeed. We could maybe imagine do away with c_std in 4.9...

Paolo.