You did NOT understand.

The reason N1::f() should be choosen is because it's in the SAME
namespace as N1:g(), and NOT because it was declared before N2:f().

That's why I gave the paralel "global function versus member function"
name resolution example.

The Examples AGAIN ( somewhat re-ordered for clarity ) :

namespace N1 { // re-ordered for clarity
        void g();
        };

namespace N2 {
        void f();
        };

namespace N1 { // moved here for clarity
        void f();
        };


using namespace N1;
using namespace N2;

void N1::g() {
        f(); // here is the BUG in the language. Should use N1::f(). See
Below.
        }

The paralel "global function versus member function" name resolution :

void f();

class X {
        void f();
        void g();
        };

void X::g() {
        f(); // here it's OK. calls X::f() and NOT ::f()
        }

Just think of a namespace as a class declaration.

In the second example, X::f() is choosen simply because it's in the SAME
scope as X::g().

So why not do so for namespaces ?

I think this is a logical solution to the problem of name resolution
between namespaces. It does NOT intreduce new problems, since we already
know that the same name resolution method is used with global functions
and classes, as shown in the second example.

Since, for instance, only one "void f()" can exists in a namespace ( as
in a class ), the language can choose N1::f() simply because it's in the
SAME namespace as the calling function, N1:g(), and can make a "bad
thing" since the rules are clear ( and already working ).

And again, this is EXACTLY what happens in the second example, X::f() is
choosen simply because it's in the SAME name scope as the calling
function, in this case X::g().

This will solve the problem of defining the template operator <,>,!=
etc. functions if the classes that USES your classes will be in the SAME
namespace as your classes, thus the calls for those template function
will resolve to YOUR functions, instead of STL's, and this is simply (
everything is simple here ? ) because they are in the SAME namespace as
your templates.

HTH,

Will someone send this proposed correction to the draft to the standard
committe ?



-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.

In article <40ebvt$88f@lyman.pppl.gov>,
Etay Bogner  <Etay_Bogner@mail.stil.scitex.com> wrote:
>You did NOT understand.

Neither did you!

>namespace N1 { void g(); };
>namespace N2 { void f(); };
>namespace N1 { void f(); };
>
>using namespace N1;
>using namespace N2;
>
>void N1::g() {
>        f(); // here is the BUG in the language. Should use N1::f().

There's no bug. It DOES use N1::f().

>        }
>
>This will solve the problem of defining the template operator <,>,!=
>etc. functions if the classes that USES your classes will be in the SAME
>namespace as your classes, thus the calls for those template function
>will resolve to YOUR functions, instead of STL's, and this is simply (
>everything is simple here ? ) because they are in the SAME namespace as
>your templates.

BE CAREFUL! We're talking about HIDING here. Consider:

namespace A { class U {}; void f(U); }
using namespace A;
namespace B {
class V {};
void f(V);
void k() {
U u;
f(u); // ERROR!
}
}

It's an ERROR here because f is B::f and the only visible
signature is f(V).

This DOESN'T happen for operator symbols, where a new rule
says lookup continues into the namespace of the
types of the arguments before overload resolution.
(proposed by Andrew Koenig, so I call this "Koenig Lookup")

--
JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
Maxtal Pty Ltd,
81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
NSW 2037, AUSTRALIA     Phone: 61-2-566-2189
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]