Ambiguous MsVC!

[miguel.a.guedes]

Hello everyone,

Please consider the following bit of code:

namespace x
{
class X
{
public:
X(){}
~X(){}
void set(int a) {i=a;}
int i;
};
}

x::X X;


int _tmain(int argc, _TCHAR* argv[])
{
using namespace x; // commenting this out shuts up the compiler's
whining

X.set(4); // error C2872: 'X' : ambiguous symbol
// could be 'c:\temp\test\test\test\test.cpp(27) : x::X X'
// or 'c:\temp\test\test\test\test.cpp(18) : x::X'
}


Isn't the compiler supposed to automatically resolve the ambiguity
since X.set(4) refers to *instance X* and not class X? In fact, I
don't see any ambiguity whatsoever. X.set(4) clearly refers to
'instance X' and not abstract type X, as that would implicate using
the operator '::'.

What do the standards say on this?


PS: I think I'm just gonna have to go back to prefixing every class
name with some letter. I can't afford to be bothered with these stupid
puzzles involving ridiculous ambiguities!

 

[Phlip]

Isn't the compiler supposed to automatically resolve the ambiguity
since X.set(4) refers to *instance X* and not class X? In fact, I
don't see any ambiguity whatsoever. X.set(4) clearly refers to
'instance X' and not abstract type X, as that would implicate using
the operator '::'.

What do the standards say on this?

I don't know. But, at a guess, I think you are expecting the compiler to use
the dot . to help it look up the symbol. At X time, before the dot, all the
compiler knows is the current scope contains two co-eval X symbols, so it
will decline to pick one.

If it instead silently picked one, and if you changed your namespacies, then
the compiler might silently pick another one, and that would be bad.

 

[Alf P. Steinbach]

* (e-mail address removed):

Hello everyone,

Please consider the following bit of code:

namespace x
{
class X
{
public:
X(){}
~X(){}
void set(int a) {i=a;}
int i;
};
}

x::X X;


int _tmain(int argc, _TCHAR* argv[])
{
using namespace x; // commenting this out shuts up the compiler's
whining

X.set(4); // error C2872: 'X' : ambiguous symbol
// could be 'c:\temp\test\test\test\test.cpp(27) : x::X X'
// or 'c:\temp\test\test\test\test.cpp(18) : x::X'
}


Isn't the compiler supposed to automatically resolve the ambiguity
since X.set(4) refers to *instance X* and not class X? In fact, I
don't see any ambiguity whatsoever. X.set(4) clearly refers to
'instance X' and not abstract type X, as that would implicate using
the operator '::'.

What do the standards say on this?

Probably nobody here can afford to be bothered with checking out the
standard for you.

However, almost as good: run the code through Comeau Online.

Of course, for that you need to first use a standard "main" function.

 

[Phlip]

Anyway, I have no other way but to go back to my old ways and prefix
my class names with a letter so as to avoid running into ambiguities.

You could also try naming the namespaces different from the classes.

 

[miguel.a.guedes]

Probably nobody here can afford to be bothered with checking out the
standard for you.

However, almost as good: run the code through Comeau Online.

Of course, for that you need to first use a standard "main" function.

I've just done it and it generates similar errors, which means MsVC is
right. I guess that what angered me was that I thought I'd never run
into this sort of problems by using non-prefixed class names.

Anyway, I have no other way but to go back to my old ways and prefix
my class names with a letter so as to avoid running into ambiguities.

Thanks for your reply, Alf.

 

[AG]

x::X X;
This looks awful to me. Why don't you rather change the name of your
variable instead. A variable and its type are two different things.

You never name your son 'son'. You must give him a real name.

AG.

 

[Bo Persson]

(e-mail address removed) wrote:
:: Alf P. Steinbach wrote:
:::
::: Probably nobody here can afford to be bothered with checking out
::: the standard for you.
:::
::: However, almost as good: run the code through Comeau Online.
:::
::: Of course, for that you need to first use a standard "main"
::: function.
:::
::
:: I've just done it and it generates similar errors, which means
:: MsVC is right. I guess that what angered me was that I thought I'd
:: never run into this sort of problems by using non-prefixed class
:: names.
::
:: Anyway, I have no other way but to go back to my old ways and
:: prefix my class names with a letter so as to avoid running into
:: ambiguities.
::

The other option, of course, is to stop using namespace directives,
which introduce the ambiguity in the first place.


Bo Persson

 

[miguel.a.guedes]

This looks awful to me. Why don't you rather change the name of your
variable instead. A variable and its type are two different things.

You never name your son 'son'. You must give him a real name.

AG.

Agreed. However, I'm dealing with a few classes that were designed to
be singletons and statically instantiated, ie a class FontsManager is
instantiated as FontsManager. Thus, there are no "sons" here.

AFAIK the only solution is to change the name of the class. Maybe
someone has a better solution for this that doesn't involve (1)
removing the namespace and (2) changing the instance variable name?

Any comments/suggestions will be greatly appreciated.

 

[Alf P. Steinbach]

* (e-mail address removed):

Agreed. However, I'm dealing with a few classes that were designed to
be singletons and statically instantiated, ie a class FontsManager is
instantiated as FontsManager. Thus, there are no "sons" here.

AFAIK the only solution is to change the name of the class. Maybe
someone has a better solution for this that doesn't involve (1)
removing the namespace and (2) changing the instance variable name?

Any comments/suggestions will be greatly appreciated.

It's stupid to try to blur the distinction between things that need to
be treated distinctly.

It's also generally stupid to use global variables.

To address both these points, introduce a static member function
instance() that provides a reference to the singleton instance.