Re: libstdc++/3026

[Giacomo Catenazzi <cate@math.ethz.ch>]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Giacomo Catenazzi <cate@math.ethz.ch>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: pme@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Thu, 07 Jun 2001 09:52:14 +0200

 Gabriel Dos Reis wrote:
 > 
 > Giacomo Catenazzi <cate@math.ethz.ch> writes:
 > | 
 > |  Ok, but there is also the main problem:
 > |  why not to change also ::acosl into std::acosl (and this change
 > |  for few other math functions) ?
 > 
 > Ideally we should be doing something to that effect.  But the details
 > and issues aren't tht crystal clear -- trust me, we're working on
 > fixes.
 > 
 > -- Gaby
 
 An other problem: Should '#include <complex>' define functions/classes
 in std namespace, without exporting it in global namespace?
 Now <complex> and <complex.h> are the same, and both use global
 namespace.
 
 [
 My problem:
 I works on a huge numeric library. It define 'real' as normal float type.
 Now I should add templates to support complex numbers.
 But complex.h uses 'real' as function (to return the real part of a
 complex number).
 Nesting the header file in a 'foo' namespace was the workaround for
 gcc 2.9x. (with an addithin: using ::istream and ostream).
 In pre 3.0 it doesn't works, thus this bug report.
 Now I'm searching a manner to split the global (library namespace)
 with the complex namespace. (The library is too huge to rename
 the library 'real' type).
 ]
 
 If you define the whole complex library in std namespace, I think
 the problem is solved. (but some bad preprocessors macros for
 worksaround in gcc 2.9x).
 
 	giacomo