public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/3026
@ 2001-06-05 10:06 Benjamin Kosnik
0 siblings, 0 replies; 10+ messages in thread
From: Benjamin Kosnik @ 2001-06-05 10:06 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: pme@gcc.gnu.org
Cc: cate@debian.org, gcc-gnats@gcc.gnu.org, pme@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Tue, 5 Jun 2001 09:53:05 -0700 (PDT)
thanks for looking at this phil.
> is permitted in userland by [17.4.1.1]/2, "All library
> entities ... are defined within the namespace std or
> namespaces nested within namespace std." Here we're
> nesting namespace std inside another namespace.
good point.
> If this code is valid, then I think this becomes another
> "funky C wrapping header problem" PR.
I think you are right, and that this code is not allowed.
Thoughts?
-benjamin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-07 9:26 Gabriel Dos Reis
0 siblings, 0 replies; 10+ messages in thread
From: Gabriel Dos Reis @ 2001-06-07 9:26 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: "Catenazzi, Giacomo Amabile" <giacomoamabile.catenazzi@cepe.mavt.ethz.ch>
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>, cate@dplanet.ch,
gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 07 Jun 2001 18:23:31 +0200
"Catenazzi, Giacomo Amabile" <giacomoamabile.catenazzi@cepe.mavt.ethz.ch> writes:
| Gabriel Dos Reis wrote:
| >
| > Giacomo Catenazzi <cate@math.ethz.ch> writes:
| >
| > | Gabriel Dos Reis wrote:
| > |
| > | 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.
| >
| > There is nothing named <complex.h> specified by C++. The standard
| > header <complex> defines its entities only in namespace std. I
| > strongly suggest you stick to those standard interfaces.
| >
|
| Ok. Sorry. Confused about different version of library.
| BTW
| . #include <complex>
| . int foo(std::complex<double> z) {
| . return int(real(z));
| . }
| This code will compile on http://www.codesourcery.com/gcc-compile.shtml
| thus 'real' is in also on global namespace.
No, the conclusion doesn't follow. `real' is in the standard namespace.
It is found thanks to Koenig lookup.
-- Gaby
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-07 8:06 Catenazzi, Giacomo Amabile
0 siblings, 0 replies; 10+ messages in thread
From: Catenazzi, Giacomo Amabile @ 2001-06-07 8:06 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: "Catenazzi, Giacomo Amabile"
<giacomoamabile.catenazzi@cepe.mavt.ethz.ch>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: cate@dplanet.ch, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Thu, 07 Jun 2001 17:17:08 +0200
Gabriel Dos Reis wrote:
>
> Giacomo Catenazzi <cate@math.ethz.ch> writes:
>
> | Gabriel Dos Reis wrote:
> |
> | 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.
>
> There is nothing named <complex.h> specified by C++. The standard
> header <complex> defines its entities only in namespace std. I
> strongly suggest you stick to those standard interfaces.
>
Ok. Sorry. Confused about different version of library.
BTW
. #include <complex>
. int foo(std::complex<double> z) {
. return int(real(z));
. }
This code will compile on http://www.codesourcery.com/gcc-compile.shtml
thus 'real' is in also on global namespace.
[But I'm not sure about the standard: the functions/classes should be in
std namespace, but they can be exported implicitly in the global
namespace?]
giacomo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-07 5:46 Gabriel Dos Reis
0 siblings, 0 replies; 10+ messages in thread
From: Gabriel Dos Reis @ 2001-06-07 5:46 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: cate@dplanet.ch
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>, pme@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 07 Jun 2001 14:44:41 +0200
Giacomo Catenazzi <cate@math.ethz.ch> writes:
| 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.
There is nothing named <complex.h> specified by C++. The standard
header <complex> defines its entities only in namespace std. I
strongly suggest you stick to those standard interfaces.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-07 0:56 Giacomo Catenazzi
0 siblings, 0 replies; 10+ messages in thread
From: Giacomo Catenazzi @ 2001-06-07 0:56 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-06 11:16 Gabriel Dos Reis
0 siblings, 0 replies; 10+ messages in thread
From: Gabriel Dos Reis @ 2001-06-06 11:16 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: Giacomo Catenazzi <cate@math.ethz.ch>
Cc: pme@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 06 Jun 2001 20:06:12 +0200
Giacomo Catenazzi <cate@math.ethz.ch> writes:
| The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
|
| From: Giacomo Catenazzi <cate@math.ethz.ch>
| To: pme@gcc.gnu.org
| Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org
| Subject: Re: libstdc++/3026
| Date: Wed, 06 Jun 2001 17:32:27 +0200
|
| pme@gcc.gnu.org wrote:
| >
| > Egads. A bunch of problems conspiring together.
| >
| > On one hand, the c_std headers are being used, which are
| > known to be nonconforming in this respect. Replacing the
| > installed std_cstddef.h with the one from c_shadow solves
| > the initial 'size_t/ptrdiff_t not declared' problem.
| >
| > On the other hand, /usr/include/stdlib.h starts giving
| > parse errors due to its lack of knowledge about namespace
| > std and namespaces in general; unqualified use of 'size_t'
| > breaks in this case.
| >
|
| 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-06 8:36 Giacomo Catenazzi
0 siblings, 0 replies; 10+ messages in thread
From: Giacomo Catenazzi @ 2001-06-06 8:36 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Giacomo Catenazzi <cate@math.ethz.ch>
To: pme@gcc.gnu.org
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Wed, 06 Jun 2001 17:32:27 +0200
pme@gcc.gnu.org wrote:
>
> Egads. A bunch of problems conspiring together.
>
> On one hand, the c_std headers are being used, which are
> known to be nonconforming in this respect. Replacing the
> installed std_cstddef.h with the one from c_shadow solves
> the initial 'size_t/ptrdiff_t not declared' problem.
>
> On the other hand, /usr/include/stdlib.h starts giving
> parse errors due to its lack of knowledge about namespace
> std and namespaces in general; unqualified use of 'size_t'
> breaks in this case.
>
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) ?
This should correct the error:
/usr/local/include/g++-v3/bits/std_cmath.h: In function `long double
foo::std::acos(long double)':
/usr/local/include/g++-v3/bits/std_cmath.h:121: `::acosl'
undeclared (first use here)
giacomo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-05 13:16 Gabriel Dos Reis
0 siblings, 0 replies; 10+ messages in thread
From: Gabriel Dos Reis @ 2001-06-05 13:16 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: pme@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 05 Jun 2001 19:52:28 +0200
pme@gcc.gnu.org writes:
| Gripping hand, I'm not entirely certain that
|
| namespace foo {
| #include <something_standard.h>
| }
Such constructs lead to undefined behaviour. Period. Nobody should
be writing something like that unless he/she knows what he/she is
doing.
-- Gaby
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-05 9:36 pme
0 siblings, 0 replies; 10+ messages in thread
From: pme @ 2001-06-05 9:36 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: pme@gcc.gnu.org
To: bkoz@gcc.gnu.org, cate@debian.org, gcc-gnats@gcc.gnu.org, pme@gcc.gnu.org
Cc:
Subject: Re: libstdc++/3026
Date: 5 Jun 2001 16:35:36 -0000
Synopsis: namespace errors in <complext.h> and other .h
State-Changed-From-To: open->analyzed
State-Changed-By: pme
State-Changed-When: Tue Jun 5 09:35:36 2001
State-Changed-Why:
Egads. A bunch of problems conspiring together.
On one hand, the c_std headers are being used, which are
known to be nonconforming in this respect. Replacing the
installed std_cstddef.h with the one from c_shadow solves
the initial 'size_t/ptrdiff_t not declared' problem.
On the other hand, /usr/include/stdlib.h starts giving
parse errors due to its lack of knowledge about namespace
std and namespaces in general; unqualified use of 'size_t'
breaks in this case.
Gripping hand, I'm not entirely certain that
namespace foo {
#include <something_standard.h>
}
is permitted in userland by [17.4.1.1]/2, "All library
entities ... are defined within the namespace std or
namespaces nested within namespace std." Here we're
nesting namespace std inside another namespace.
If this code is valid, then I think this becomes another
"funky C wrapping header problem" PR.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3026&database=gcc
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++/3026
@ 2001-06-04 11:06 bkoz
0 siblings, 0 replies; 10+ messages in thread
From: bkoz @ 2001-06-04 11:06 UTC (permalink / raw)
To: pme; +Cc: gcc-prs
The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
From: bkoz@gcc.gnu.org
To: cate@debian.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
pme@gcc.gnu.org
Cc:
Subject: Re: libstdc++/3026
Date: 4 Jun 2001 17:59:58 -0000
Synopsis: namespace errors in <complext.h> and other .h
Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: bkoz
Responsible-Changed-When: Mon Jun 4 10:59:58 2001
Responsible-Changed-Why:
Perhaps you could look at this one?
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3026&database=gcc
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-06-07 9:26 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-05 10:06 libstdc++/3026 Benjamin Kosnik
-- strict thread matches above, loose matches on Subject: below --
2001-06-07 9:26 libstdc++/3026 Gabriel Dos Reis
2001-06-07 8:06 libstdc++/3026 Catenazzi, Giacomo Amabile
2001-06-07 5:46 libstdc++/3026 Gabriel Dos Reis
2001-06-07 0:56 libstdc++/3026 Giacomo Catenazzi
2001-06-06 11:16 libstdc++/3026 Gabriel Dos Reis
2001-06-06 8:36 libstdc++/3026 Giacomo Catenazzi
2001-06-05 13:16 libstdc++/3026 Gabriel Dos Reis
2001-06-05 9:36 libstdc++/3026 pme
2001-06-04 11:06 libstdc++/3026 bkoz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).