Re: [QNX6][math] Test failures with Dinkumwarelibrary(qcc-3.3.5-cpp)
Before I submit this point to QNX please comment on the text below taken
from the QNX documentation for the Dinkumware C++ library.
>>The way this library is constructed seems to be that in general if you
>>use the C++ 'c*' equivalent of a C '*.h' header, all the functions get
>>promoted into the std namespace. This is not the first time we have
>>encountered this problem.
> Just to clarify: if the symbol is part of the C++ std then it should be in
> namespace std only when you include the <c*> header. However, symbols that
> are not part of the C++ std (log1p, expm1 etc) should *never* be in
> namespace std, at least according to the letter of the std.
//-- QNX/Dinkumware docs for 'cmath'.
(c) 1992-2002 by P.J.Plauger. All rights reserved.
Include the standard header <cmath> to define the macros traditionally
defined in the Standard C library header <math.h>. Including this header
also ensures that the names declared with external linkage in the
Standard C library header are declared in the std namespace. In this
implementation, the names may or may not also be declared in the global
namespace, depending on the specific translation environment.
#if <TRADITIONAL C HEADERS>
Re: [QNX6][math] Test failures withDinkumwarelibrary(qcc-3.3.5-cpp)
> Before I submit this point to QNX please comment on the text below
> taken from the QNX documentation for the Dinkumware C++ library.
OK it depends on how pedantic you want to be: I don't believe this is an
important issue, but if you're being really *very* pedantic there should be
*nothing* declared in namespace std that isn't specified in the standard.
If this rule isn't followed you nasty backwards-compatibity problems if the
non-standard name later become standardised but with different semantics to
the existing vendor-specific one. We have past experience of this with
non-standard hash_set/hash_map implementations in namespace std. Having
said all that, there is no other meaning that log1p/expm1 can reasonably
take than their C99 defined ones, so I *really* can't imagine that this
particular case is actually a real problem.
Basically if I were you I wouldn't bother reporting this one, it's not worth