Re: [OT] calling isnan
Re: [OT] calling isnan
- Subject: Re: [OT] calling isnan
- From: Andreas Grosam <email@hidden>
- Date: Wed, 23 Feb 2005 16:52:51 +0100
On 19.02.2005, at 02:27, Bill Northcott wrote:
I spent some time going around this with the R people.
Basically the story is this:
isnan() is a C99 extension to standard C.
Standard C++ is based on an older standard of C.
Hence isnan() is not part of standard C++ and may or may not work.
Thank you Bill for this explanation.
So, when does it may or may not work?
The doc says about this extensions:
These extensions are available in C and Objective-C. Most of them are also available in C++. Some features that are in ISO C99 but not C89 or C++ are also, as extensions, accepted by GCC in C89 mode and in C++.
Which extension is available depends on the state of certain configure flags which may be set when the compiler, the clib and the C++ lib will be compiled. The Apple specific build system is somewhat different than the FSF version and is not as well documented.
So, when compiling the libstdc++ library, it requires that we configure the whole chain, from the compiler to the library - since there are dependencies. The configure script for libstdc++ may affect the macro _GLIBCPP_USE_C99 which is then put into the header /bits/c++config.h during the configure process. This macro determines whether or not C99 features are available in C++.
When compiling the C++ lib, the C99 configure flag is on by default to get the C99 features, but it will be disabled automatically by the config mechanism when the necessary support for the C99 is not found. Also, it can be disabled by hand.
So, i guess, if we do not have complete C99 support from the clib or the compiler, the macro _GLIBCPP_USE_C99 will not be defined. Also, we do not have C99 functions - even in global namespace - because they do not exist.
Well, if _GLIBCPP_USE_C99 is defined, the C++ style include headers undef the C99 macros and define corresponding functions and move them from global namespace into namespace std. The intended usage is, that if C99 is enabled, the C99 features become functions in namespace std.
Surprisingly, on my system, _GLIBCPP_USE_C99 is not defined. But i can not believe, that we do not have complete support in the compiler and the clib - in version 3 (libstdc++ v3). There are reasons to suspect an issue in the config mechanism, too.
Now, the effect is, since many of the C99 features are actually available, the macros will not be undefed but they still remain in global namespace.
For instance the function
<x-tad-bigger>snprintf</x-tad-bigger>() has a C99 and a C90 variant as a built-in function. The compiler defaults to compile in C99. Thus, presumably snprintf() is in C99. When linking against the libstdc++ library, and including the header <cstdio> we get the prototype for snprintf(). Since - on my system - the macro _GLIBCPP_USE_C99 is not defined (in header file /bits/c++config), snprintf() is not namespace std - but remains defined in global namespace.
Otherwise, if _GLIBCPP_USE_C99 would be defined, the macro snprintf would be undefed, and a corresponding function would be declared in namespace std.
The documention does not mention that we can set or redefine the macro _GLIBCPP_USE_C99 when using the C++ lib in our programs. For some other macros this is allowed, though.
Well, I do not know, whether this configure flag has been disabled by hand or whether there is no sufficient C99 support - or if there is just a bug in the config mechanism. But when there would be no sufficient support, why are C99 features available through the clib?
I also do not know whether the macro _GLIBCPP_USE_C99 is "read_only" - or, if this macro can be defined by the programmer when including C++ headers.
In the C++ sources itself, the macro is checked in several template functions - which may explicitly instantiated and thus part of the library. However, regarding the implementation, it just determines whether to use C99 functions from the clib or to use alternative (better) approaches.
I took a look in the sources in order to figure out how the config mechanism may or may not set this macro, but - frankly, it is a nasty job and without further knowledge of how Apple uses configure flags when building the libraries and compilers, it is also pretty useless.
I would appreciate it if somebody can really clarify this in detail.
Regards
Andreas Grosam
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden