[Bug c++/20687] New: namespace bug
>From the example in 7.3.4.1 (international standard
ISO/IEC 14882) we can conclude that
the names introduced by using directive hide
the names in higer level namespaces instead of
resulting in an ill-formed code.
In the source code attached __false_type should
be recognized correctly as comming from namespace
_STL and should not conflict with the top level
definition of __false_type. This is so since
namespace std contains using namepsace _STL and
the namespace _STL contains definition of
__false_type too.
Below is part of preprocesed file
$ gcc --version
gcc (GCC) 4.0.0 20050319 (prerelease)
compile command :
c++ -pthread -fexceptions -I../stlport -W -Wno-sign-compare \
-Wno-unused -Wno-uninitialized -D_STLP_USE_GLIBC \
-O0 -gstabs+ -g3 -fPIC -D_STLP_DEBUG -fPIC complex_exp.cpp \
-c -o ../lib/obj/GCC-LINUX/DebugSTLD/complex_exp.o
next was cut from preprocesed complex_exp.i.cpp:
namespace std { }
namespace __std_alias = std;
namespace _STL {}
namespace std {
using namespace _STL;
}
namespace _STL {
using namespace __std_alias;
}
namespace _STL {
struct __true_type {};
struct __false_type {};
template struct __bool2type {
typedef __false_type _Ret;// this is OK
};
template<>
struct __bool2type<1> { typedef __true_type _Ret; };// this is OK
}
namespace _STL {}
namespace std {
using namespace _STL;
}
struct __true_type { };
struct __false_type { };
namespace std
{
template
struct __truth_type
{ typedef __false_type __type; }; // should be OK too, but report error:
'__false_type' does not name a type
template<>
struct __truth_type
{ typedef __true_type __type; };// should be OK too, but report error:
'__true_type' does not name a type
}
Whole file is too long (2 row) - if it is needed please let me know,
I will send it.
(OS is Fedora core 3 at Linux kernel 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004
i686 i686 i386 GNU/Linux)
--
Summary: namespace bug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jozef at syncad dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20687
[Bug c++/20687] namespace bug
--- Additional Comments From jozef at syncad dot com 2005-03-30 14:56
---
Subject: Re: namespace bug
Hi,
This is not about the same :
7.3.4.5
d1++; // shows that there is a conflict between a symbol in your
// namespace and a symbol imported using using namespace
f(1); // shows that there is a conflict between two symbols;
// both imported from two namespaces; one directly,
// the second transitively
None of the errors indicated show that there is a conflict
between a symbol imported from a namespace and a symbol
from a higher level namespace.
But the example in the first paragraph clearly states that
the imported names hide names from the higher levels:
7.3.4.1
i = 5; // OK, C::i visible in B and hides A::i
7.3.4.5 does not conflict with 7.3.4.1. It still looks
to me reasonable that the names imported using namespace have higher
precedence than names inherited from a higher level namespace
(this would be similar to the fact that the names defined
in a namespace have higher precedence to the names inherited
from a higher level namespaces).
One more argument is that this feature is required to compile correctly STLport.
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
> 19:51 ---
> The reduced testcase:
> namespace dd {
> struct t1 {};
> }
> namespace ff {
> using namespace dd;
> }
> struct t1 { };
> namespace ff
> {
> typedef t1 t2;
> }
>
>
> But the use of t1 is ambiguous really as "using namespace" is not as strong
> as defining the t1 in the
> namespace ff or doing a "using dd::t1" in the namespace ff.
>
Can you provide some reference to the standard for this claim, please?
Regards,
Jozef
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20687
