Dennis Wilkinson schreef:
> I've read and reread the basic.lookup.* sections of the standard, and
> class Foo
> {
> public:
>  enum EHow { eDoItThisWay, eDoItThatWay };
>
>  Foo() {}
>  ~Foo() {}
>
>  void doSomething( EHow inWhat ) {}
> };
>
> What I would like to do is to call doSomething with one of my enum's
> values, unqualified, such as:
>
> Foo aFoo;
> aFoo.doSomething ( eDoItThisWay );
>
> This fails to compile in all of the compilers mentioned above, as the
> unqualified enum value is not looked up in the space of Foo class,
> meaning I have to call this way:
>
> Foo aFoo;
> aFoo.doSomething( Foo::eDoItThisWay );
>
.
> I'd like to propose that in
> cases like this (possibly strictly for the member function call case)
> that unqualified names be looked up first in the same scope as the
> function, then looked up in the parent spaces. It seems reasonable
> (although I admittedly not a 'parser guy') to expect that the parser
> would have knowledge of the names within the class whose member is
> being invoked.

I'm not happy. With normal functions, the function name is looked up
in a scope determined by its arguments (Koenig lookup/ADL). I.e. the
lookup is inside-out. You propose an outside-in lookup.

This is probably a real problem for operators that could be either
members or non-members. E.g. IOstream's operator<<, which names a mix
of member and non-member functions.

Regards,
Michiel Salters (who wouldn't call himself a parser guy either)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I've read and reread the basic.lookup.* sections of the standard, and
I'm not clear if what I'm looking at here is a failure of the compilers
I've looked at (most recent MS Visual Studio.NET, gcc 3.3, most recent
CodeWarrior).

In the interest of avoiding boolean parameters that make calling code
impossible to read without trotting off to find a header, while at the
same time trying to limit the scope of my types appropriately, I tend
to end up with enums declared at class scope and member functions that
take those enums as parameters, such as the following trivial example:

class Foo
{
public:
 enum EHow { eDoItThisWay, eDoItThatWay };

 Foo() {}
 ~Foo() {}

 void doSomething( EHow inWhat ) {}
};

What I would like to do is to call doSomething with one of my enum's
values, unqualified, such as:

Foo aFoo;
aFoo.doSomething ( eDoItThisWay );

This fails to compile in all of the compilers mentioned above, as the
unqualified enum value is not looked up in the space of Foo class,
meaning I have to call this way:

Foo aFoo;
aFoo.doSomething( Foo::eDoItThisWay );

If you have more than one such enum 'switch' parameter in a particular
function's signature, this becomes very awkward, littering the call
with lots of explicit Foo:: qualifiers. Moving the enum declarations to
global scope (or to the scope containing the class) isn't a good
solution since there's no reason to muddy that namespace and it
introduces lots of potential collisions. Obviously this isn't limited
strictly to enum lookup, but that's where I run into it most
frequently.

If this is an issue with the standard, I'd like to propose that in
cases like this (possibly strictly for the member function call case)
that unqualified names be looked up first in the same scope as the
function, then looked up in the parent spaces. It seems reasonable
(although I admittedly not a 'parser guy') to expect that the parser
would have knowledge of the names within the class whose member is
being invoked.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]