This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Namespace Issue


Stephan T. Lavavej wrote:

> namespace meow {
>     struct mlar { };
> }
>
> namespace oink {
>    using namespace meow;
>
>    void fxn(mlar s);
> }
>
> void oink::fxn(/* LOOK HERE */ mlar s) { }
>
> Note that namespace qualification is omitted on the parameter type in
> the definition: mlar s instead of meow::mlar s.
>
> gcc 3.3.3 and the online Comeau compiler (and, I am told, gcc 3.4.0)
> accept this code without complaint; MSVC 7.1 rejects it.  I believe
> that gcc is correct to accept it, but I don't know if the code is
> legal, so this may be a gcc bug.

No, GCC is correct.

> I've looked through the Standard (haven't found anything that
> addresses this issue)

It's [basic.lookup.unqual]/6: "A name used in the definition of a function(*)
that is member of namespace N [...] shall be declared before its use in the
block in which it is used, or in one of its enclosing block, or shall be
declared before its use in namespace N [...]".  The footnote says: "(*) This
refers to unqualified names following the function declarator; such a name may
be used as a type or as a default argument name in the
parameter-declaration-clause, or may be used in the function body."

So, the footnote explains that, for the purpose of unqualified name lookup, the
names looked up as types or default arguments in the parameter-declaration
clause follow exactly the same rules of the name defined in the body of the
function. In other words, The compiler will use the same algorithm to lookup
"mlar" in the following two cases:

void oink::fxn(mlar s) { }
void oink::fxn(void) { mlar s; }

I assume it is intuitive for you that, in the latter case, mlar is correctly
found in name lookup. The first snippet I quoted is what mandates this, in fact
it basically says that such a name must be declared before its use either in
the block itself (within the function) or in its enclosing block (which is
where the function definition appears, that is in global namespace), or in
namespace N (where N is the namespace that the function is member of, "oink").

> The Standard should also explain why gcc (correctly, I
> think) rejects omitted qualification on return types in definitions.

Yes, because return types do not appear AFTER the function declarator, so they
do not belong to the definition of a function. The footnote is clear about
this. This means that the return type is lookedup using normal unqualified
lookup, which will not look within "oink".

> Is the code legal?

Definitely.

Giovanni Bajo



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]