Valid C++?

[Boris]

Is this a valid C++ program (according to the C++ standard)? I ask as I'm
trying to port a Windows library to Solaris, and the Solaris C++ compiler
reports an error (The name x is ambiguous in ns1: ns2::x and ns1::x). The
code below reproduces the problem, and I wonder now if I have to adapt the
code or submit a bug report to Sun?

namespace ns1 {
struct x { };
}

namespace ns2 {
using namespace ns1; // If this line is removed ...
void x(); // ... or this line the code compiles.
struct x { };
}

int main()
{
struct ns2::x x;
}

 

[Alf P. Steinbach]

* Boris:

Is this a valid C++ program (according to the C++ standard)? I ask as
I'm trying to port a Windows library to Solaris, and the Solaris C++
compiler reports an error (The name x is ambiguous in ns1: ns2::x and
ns1::x). The code below reproduces the problem, and I wonder now if I
have to adapt the code or submit a bug report to Sun?

namespace ns1 {
struct x { };
}

namespace ns2 {
using namespace ns1; // If this line is removed ...
void x(); // ... or this line the code compiles.
struct x { };
}

int main()
{
struct ns2::x x;
}

As I recall the code is formally valid but dumb.

Since it's dumb I won't make the effort to look up the standard's
guarantees for you.

Rename.


Cheers, & hth.,

- Alf

 

[Jonathan Lane]

Is this a valid C++ program (according to the C++ standard)? I ask as I'm
trying to port a Windows library to Solaris, and the Solaris C++ compiler
reports an error (The name x is ambiguous in ns1: ns2::x and ns1::x). The
code below reproduces the problem, and I wonder now if I have to adapt the
code or submit a bug report to Sun?

namespace ns1 {
struct x { };

}

namespace ns2 {
using namespace ns1; // If this line is removed ...
void x(); // ... or this line the code compiles.
struct x { };

}

int main()
{
struct ns2::x x;

}

Clearly the "using namespace ns1" line is going to be a problem since
you're polluting your ns2 namespace with the colliding names from ns1.
I can understand that this is going to make ns2 contain ambiguous
names.

Solutions:
rename your functions and structs so that they're unique. This also
makes the maintenance a lot easier since a developer doesn't need to
think about whether you mean function x, struct x, or alternative
struct x when they read your code.

and/or don't import the whole of ns1 into ns2. Use the fully qualified
namespace name to address ns1::x. namespaces are there to prevent this
kind of collision. By importing the whole namespace you essentially
bypass that benefit.

 

[Boris]

Clearly the "using namespace ns1" line is going to be a problem since
you're polluting your ns2 namespace with the colliding names from ns1.
I can understand that this is going to make ns2 contain ambiguous
names.

Normally I'd agree. However I you remove the function declaration the code
compiles although the namespace is still polluted?

Solutions:
rename your functions and structs so that they're unique. This also
makes the maintenance a lot easier since a developer doesn't need to
think about whether you mean function x, struct x, or alternative
struct x when they read your code.

Renaming the structs would be the last resort as from a design point of
view the names used in the library make sense and represent two different
concepts which happen to have the same name. The function is also
intentionally called like the struct: The struct is a function object, and
other parts of the code might want to reuse the function without
instantiating the function object first. I have no strict opinion here as
you can come up with other conventions of course. However I shouldn't need
to if this is valid C++ code?

Boris

 

[Victor Bazarov]

* Boris:

As I recall the code is formally valid but dumb.

Since it's dumb I won't make the effort to look up the standard's
guarantees for you.

Rename.

Or remove the 'using' from 'ns2'. It really is A BAD IDEA(tm) to
have a 'using' directive in the header (no matter whether it's in
another namespace or not).

V

 

[Jonathan Lane]

Normally I'd agree. However I you remove the function declaration the code
compiles although the namespace is still polluted?

presumably then the ns2 version of the struct is hiding the ns1
version. How would you expect the compiler/your code to differentiate
between the two structs given that they're both in scope? There's
nothing to stop you having a function and struct/functor of the same
name. I'd suggest it's a bit misleading to maintenance programmers but
that's up to you of course. I guess the compiler's getting confused by
having three conflicting names. I'm sure there's a scoping rule that
affects this.

If you won't rename the structs then at least get rid of the using
directive in ns2. There's no need for it at all in this case and it's
just causing you problems.

 

[Boris]

[...]

Normally I'd agree. However I you remove the function declaration the
code
compiles although the namespace is still polluted?

presumably then the ns2 version of the struct is hiding the ns1
version. How would you expect the compiler/your code to differentiate
between the two structs given that they're both in scope? There's
nothing to stop you having a function and struct/functor of the same
name. I'd suggest it's a bit misleading to maintenance programmers but
that's up to you of course. I guess the compiler's getting confused by
having three conflicting names. I'm sure there's a scoping rule that
affects this.

If you won't rename the structs then at least get rid of the using
directive in ns2. There's no need for it at all in this case and it's
just causing you problems.

Yep, that's what I'll do. Thanks for your comments!

Boris