[Bug c++/20687] New: namespace bug

[Bug c++/20687] New: namespace bug

[jozef at syncad dot com]

>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 <int _Is> 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<bool>
    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<true>
    { typedef __true_type __type; };    // should be OK too, but report error:
'__true_type' does not name a type

}

Whole file is too long (20000 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

[pinskia at gcc dot gnu dot org]

------- 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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20687

[Bug c++/20687] namespace bug

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 19:56 -------
But look at the example for 7.3.4 P5 and you will see that this is in fact invalid.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20687

[Bug c++/20687] namespace bug

[jozef at syncad dot com]

------- 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

[Bug c++/20687] namespace bug

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-03-30 15:15 -------
> One more argument is that this feature is required to compile correctly STLport.

*Assuming* this is true, it's a serious problem for STLPort ;) because the other 
widespread C++ front-end, used by many commercial compilers, also rejects your
code...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20687