Le mer 22/09/2004 à 12:19, Jonathan Wakely a écrit :
On Wed, Sep 22, 2004 at 11:27:09AM +0200, Guillaume Melquiond wrote:
right. Version of GCC is being used in numeric/interval/detail/bugs.hpp to discover capabilities of runtime, thus problem.
Not to discover capabilities, it is to discover namespaces. At the time of GCC 3.4, the developers decided that the inverse hyperbolic functions should not be in the std namespace anymore (they were before). It is the reason why the GCC version is tested.
You still haven't say how I can detect that it's the mingw runtime that will be used. I need to know a preprocessor test so that i can adapt the interval library to this runtime.
Thanks for looking into this. This part of the code needed some cleanup. As I explained, this code was written by Jens Maurer 4 years ago in the first release of the library. And as much as possible I tried to not modify it while it worked (or I believed it did). So it's clearly outdated nowadays.
However, another test in boost/numeric/interval/detail/bugs.hpp seems wrong to me:
# if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a # elif defined(BOOST_HAS_INV_HYPERBOLIC) # define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a # endif
This implies that GCC 3.3 (and earlier) puts the inverse hyperbolic functions in namespace std. According to a simple test (*) I've just run, none of GCC 3.0.4 on linux, 3.3.3 on FreeBSD or 3.4.3 on FreeBSD declares acosh in namespace std.
FreeBSD is not necessarily a good example since there has been a few problems with respect to supporting C99 mathematical functions. But I verified with Linux, and you are right: the C99 functions did leave the std namespace a lot sooner than what I thought.
Only GCC 2.x seems to declare those functions in namespace std, but that's probably because namespace std == global namespace in GCC 2.x (all std:: qualifiers are effectively ignored)
Should the first line of the test above be changed as follows?
# if defined(__GNUC__) && (__GNUC__ == 3)
According to your information, even the version number could be ignored since GCC 2.x assumes the root and the std namespaces are equivalent.
I believe the regression tests pass because the top of the file says:
[... snipped whole explanation that makes a lot of sense, thanks ...]
Why is BOOST_HAS_INV_HYPERBOLIC defined if you're using Glibc but not libstdc++? libstdc++ doesn't make the functions unavailable, it just doesn't put them in namespace std.
I don't know; it's also something I was wondering. But since the library works and is used on a lot more platform than what I have access to, I refrained from experimenting.
Why does one test look at the stdlib macro, but the next one looks at the compiler version?
Because one of the test was written by Jens, and the other one by me later on. :)
I assume the stdlib check is to account for GCC with STLPort, but then the next test ignores that possiblity and only looks at the compiler version. I won't pretend to understand exactly what that file is trying to do. Comments might help.
The purpose of this file is to provide information so that the rest of the code doesn't have problem with namespaces. For example, at a time there was a macro BOOST_NUMERIC_INTERVAL_using_max that was dealing with the min and max locations. This code has since been factorized outside of the library in Boost.Config (BOOST_USING_STD_MAX). And so only the macros for the mathematical functions still remain here. I wouldn't mind the whole file being taken into the Boost.Config subsystem, so that I don't have to deal with these issues anymore. However, in the meantime, let's see what we can do to improve the current situation. I would modify the BOOST_HAS_INV_HYPERBOLIC macro so that it really means these C99 functions are defined. In case they are not, dummy functions would be defined in a detail namespace so that the compilers don't complain about unknown identifier, and ADL could still be used (this is mandatory). And in all cases, the BOOST_NUMERIC_INTERVAL_using_ahyp macro would point to the correct namespace (root, std, or the dummy detail one). How does it sound? Regards, Guillaume