ambiguous operator on Visual Studio 2010

[Aaron Gray]

Hello,

I am getting an ambiguous operator error in VS2010 but not in GCC 4.5.

The following code illustrates the problem :-


enum flags { OK, TEST };

inline bool operator >= (flags f1, flags f2) {
return (f1 & f2) == f2;
}

int main(int argc, char *argv[]) {
flags f1 = OK;
flags f2 = TEST;
bool b = f1 >= f2;
return 0;
}


gives the following on VS2010 :-

1> test.cpp
1>c:\test\c++\operator-test\operator-test\test.cpp(10): error C2593:
'operator >=' is ambiguous
1> c:\test\c++\operator-test\operator-test\test.cpp(3): could be 'bool
operator >=(flags,flags)'
1> or 'built-in C++ operator>=(flags, flags)'
1> while trying to match the argument list '(flags, flags)'

What is the correct ISO C++ 2004 behaviour ?

Is there a workaround other than defining a function 'bool
superset(flags,flags)' instead of operator >= ?

Many thanks in advance,

Aaron

 

[Victor Bazarov]

I am getting an ambiguous operator error in VS2010 but not in GCC 4.5.

The following code illustrates the problem :-


enum flags { OK, TEST };

inline bool operator >= (flags f1, flags f2) {
return (f1 & f2) == f2;
}

int main(int argc, char *argv[]) {
flags f1 = OK;
flags f2 = TEST;
bool b = f1 >= f2;
return 0;
}


gives the following on VS2010 :-

1> test.cpp
1>c:\test\c++\operator-test\operator-test\test.cpp(10): error C2593:
'operator >=' is ambiguous
1> c:\test\c++\operator-test\operator-test\test.cpp(3): could be 'bool
operator >=(flags,flags)'
1> or 'built-in C++ operator>=(flags, flags)'
1> while trying to match the argument list '(flags, flags)'

What is the correct ISO C++ 2004 behaviour ?

The correct behavior is to call the user-defined operator.

Seems like a bug in the compiler that can't make the correct choice
between a user-defined function with each argument's matching exactly
and the built-in operator that requires a conversion (integral
promotion). I say, report it. Comeau gets it right as well.

I believe the Visual C++ creators missed the fact that in order for the
compiler to use >= with enumeration, the integral promotion [conv.prom]
should be performed (see [expr.rel]/2), and according to
[over.ics.scs]/3 an exact match (for identity category) has a higher
rank than a promotion. A clear bug.

Is there a workaround other than defining a function 'bool
superset(flags,flags)' instead of operator >= ?

I can't think of any right now.

V

 

[Aaron Gray]

I am getting an ambiguous operator error in VS2010 but not in GCC 4.5.

The following code illustrates the problem :-


enum flags { OK, TEST };

inline bool operator >= (flags f1, flags f2) {
return (f1 & f2) == f2;
}

int main(int argc, char *argv[]) {
flags f1 = OK;
flags f2 = TEST;
bool b = f1 >= f2;
return 0;
}


gives the following on VS2010 :-

1> test.cpp
1>c:\test\c++\operator-test\operator-test\test.cpp(10): error C2593:
'operator >=' is ambiguous
1> c:\test\c++\operator-test\operator-test\test.cpp(3): could be 'bool
operator >=(flags,flags)'
1> or 'built-in C++ operator>=(flags, flags)'
1> while trying to match the argument list '(flags, flags)'

What is the correct ISO C++ 2004 behaviour ?

The correct behavior is to call the user-defined operator.

Seems like a bug in the compiler that can't make the correct choice
between a user-defined function with each argument's matching exactly and
the built-in operator that requires a conversion (integral promotion). I
say, report it. Comeau gets it right as well.

I believe the Visual C++ creators missed the fact that in order for the
compiler to use >= with enumeration, the integral promotion [conv.prom]
should be performed (see [expr.rel]/2), and according to [over.ics.scs]/3
an exact match (for identity category) has a higher rank than a promotion.
A clear bug.

Right !

I can't think of any right now.

If thats the case I'll use the function workaround.

Many thanks,

Aaron

 

[Aaron Gray]

I am getting an ambiguous operator error in VS2010 but not in GCC 4.5.

The following code illustrates the problem :-


enum flags { OK, TEST };

inline bool operator >= (flags f1, flags f2) {
return (f1 & f2) == f2;
}

int main(int argc, char *argv[]) {
flags f1 = OK;
flags f2 = TEST;
bool b = f1 >= f2;
return 0;
}


gives the following on VS2010 :-

1> test.cpp
1>c:\test\c++\operator-test\operator-test\test.cpp(10): error C2593:
'operator >=' is ambiguous
1> c:\test\c++\operator-test\operator-test\test.cpp(3): could be 'bool
operator >=(flags,flags)'
1> or 'built-in C++ operator>=(flags, flags)'
1> while trying to match the argument list '(flags, flags)'

What is the correct ISO C++ 2004 behaviour ?

The correct behavior is to call the user-defined operator.

Seems like a bug in the compiler that can't make the correct choice
between a user-defined function with each argument's matching exactly and
the built-in operator that requires a conversion (integral promotion). I
say, report it. Comeau gets it right as well.

I believe the Visual C++ creators missed the fact that in order for the
compiler to use >= with enumeration, the integral promotion [conv.prom]
should be performed (see [expr.rel]/2), and according to [over.ics.scs]/3
an exact match (for identity category) has a higher rank than a
promotion. A clear bug.

Right !

Yep ! :-

http://connect.microsoft.com/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Aaron

 

[Balog Pal]

I believe the Visual C++ creators missed the fact that in order for the
compiler to use >= with enumeration, the integral promotion [conv.prom]
should be performed (see [expr.rel]/2), and according to
[over.ics.scs]/3 an exact match (for identity category) has a higher
rank than a promotion. A clear bug.

Right !

Yep ! :-

http://connect.microsoft.com/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Ridiculous. Closed as wontfix immediately.
Anyone pays actual money for this crapware called VS? Seems it will not
change until they start to request payback. :-(

 

[Krice]

Anyone pays actual money for this crapware called VS?

No, I'm using the free Express version. It's easily the best IDE
available for Windows. Besides operators are for pussies.

 

[Bo Persson]

I believe the Visual C++ creators missed the fact that in order
for the compiler to use >= with enumeration, the integral
promotion [conv.prom] should be performed (see [expr.rel]/2),
and according to [over.ics.scs]/3 an exact match (for identity
category) has a higher rank than a promotion. A clear bug.

Right !

Yep ! :-

http://connect.microsoft.com/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Ridiculous. Closed as wontfix immediately.
Anyone pays actual money for this crapware called VS? Seems it
will not change until they start to request payback. :-(

Considering that this was reported just weeks before the final
release, perhaps there were higher impact bugs to fix first?


Bo Persson

 

[Alf P. Steinbach /Usenet]

* Bo Persson, on 08.06.2011 21:29:

I believe the Visual C++ creators missed the fact that in order
for the compiler to use>= with enumeration, the integral
promotion [conv.prom] should be performed (see [expr.rel]/2),
and according to [over.ics.scs]/3 an exact match (for identity
category) has a higher rank than a promotion. A clear bug.

Right !

Yep ! :-

http://connect.microsoft.com/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Ridiculous. Closed as wontfix immediately.
Anyone pays actual money for this crapware called VS? Seems it
will not change until they start to request payback. :-(

Considering that this was reported just weeks before the final
release, perhaps there were higher impact bugs to fix first?

Well "closed as wontfix" sounds pretty definite, like, won't fix, ever.

Anyway, with Herb in there guiding them they've improved the conformance of MSVC
greatly -- a relative improvement that they truly deserve our cheers for!

But regarding the absolute scale, well think about it, Microsoft's toolset does
not even by default accept the /minimal standard C++ program/ for the toolset's
main usage. I'm talking about standard C and C++ `main`; the MS toolset doesn't
accept a standard `main` unless one uses half-documented switches. So one should
not be too optimistic about them fixing any more subtle issue...


Cheers,

- Alf (realistic mode)

 

[Öö Tiib]

But regarding the absolute scale, well think about it, Microsoft's toolset does
not even by default accept the /minimal standard C++ program/ for the toolset's
main usage. I'm talking about standard C and C++ `main`; the MS toolset doesn't
accept a standard `main` unless one uses half-documented switches.

Really? I have never had a problem with that one.

<trying>
C:\>type test.cpp
int main(){}

C:\>cl test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj

C:\>test

C:\>
</trying>

Seems to work without strange switches? It may be that i miss
something.

 

[Alf P. Steinbach /Usenet]

* Öö Tiib, on 09.06.2011 01:06:

Really? I have never had a problem with that one.

<trying>
C:\>type test.cpp
int main(){}

C:\>cl test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj

C:\>test

C:\>
</trying>

Seems to work without strange switches? It may be that i miss
something.

Yes, you're missing that the main usage of MSVC is to create Windows GUI
subsystem applications.

You created a console subsystem app, the default for direct command line use of
the compiler, which is however not what it's mainly used for.

Windows subsystems (which define the services rendered to an application) are a
Windows feature outside the scope of the C++ standard, but you can think of each
subsystem as a kind of variant of Windows, and the main usage of MSVC is to
target the GUI variant of Windows, the GUI subsystem -- and for this main
usage, it does not support a standard `main` by default.


<example>
C:\test> echo %cl%
/nologo /EHsc /GR /Zc:forScope,wchar_t /W4

C:\test> (cl /nologo- 2>&1) | find /i "c++"
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86

C:\test> echo int main(){} >bah.cpp

C:\test> cl bah.cpp /link /subsystem:windows
bah.cpp
LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain@16
referenced in function ___tmainCRTStartup
bah.exe : fatal error LNK1120: 1 unresolved externals

C:\test> rem AS YOU CAN SEE, UNGOOD

C:\test> rem FIX (NOT PARTICULARLY WELL-DOCUMENTED):

C:\test> cl bah.cpp /link /subsystem:windows /entry:mainCRTStartup
bah.cpp

C:\test> _
</example>


By the way, this is not version 16.0 of MSVC. It's maybe version 16.0 of Lattice
C, to the degree that that old beast is still alive within MSVC. It's version
16.0 - 6 = 10.0 of MSVC. ;-)

And don't expect that version reporting to be fixed soon, either. ;-)


Cheers & hth.,

- Alf

 

[Krice]

Yes, you're missing that the main usage of MSVC is to create Windows GUI
subsystem applications.

Well, if you think of it as the main usage. It's just one option
in the list when you create a project. Trust me, it's perfectly
possible to write standard C++ in VS. Well, apart from some
rare language weirdnesses that only compile in Comeau.

 

[Balog Pal]

Considering that this was reported just weeks before the final release,
perhaps there were higher impact bugs to fix first?

Is that relevant? I don't dispose over billions still can give lifetime
guarantee on anything I deliver, fixing defects for free. I'd consider
anything less as cheating. Actually normal laws always have clauses about
'defective delivery'.

In this case defect is clear and acknowledged. It should be fixed. It is
not. This puts the company on the level of frauds and petty cheats. and
blatant ones, as they actually have a procedure of evaluation, have that
'triage', just is is set to allow such closures.

Certainly this is not the first case or an isolated one. I recall we
discussed a code generation bug here, when destructor was not called if
there was odd number of returns and throws in a function -- there Herb
Sutter himself promised that it will be fixed promptly, then it was also
closed as wontfix, same bullshit reasons. 'Respect for the customer' have
a very special meaning around there.

 

[Öö Tiib]

* Öö Tiib, on 09.06.2011 01:06:

Yes, you're missing that the main usage of MSVC is to create Windows GUI
subsystem applications.

Oh but having GUI is undefined behavior in C++. Windows itself
started like GUI framework for MS DOS originally. Since Windows NT it
became operating system. Compiler still accepts int main() and
produces applications without strange GUI-enabling switches (like /
subsystem:windows).

You created a console subsystem app, the default for direct command line use of
the compiler, which is however not what it's mainly used for.

Windows subsystems (which define the services rendered to an application)are a
Windows feature outside the scope of the C++ standard, but you can think of each
subsystem as a kind of variant of Windows, and the main usage of MSVC is to
target the GUI variant of Windows, the GUI subsystem  --  and for this main
usage, it does not support a standard `main` by default.

Yes, you can put it that way too. Well ... lot of code works command
line. Just input something, do something, output some html or xml and
done. If there has to be interactive GUI then i somehow prefer Qt to
MS GUI and OpenGL to DirectX. Compiles and works with MSVC. Also
friendly i(something) and Linux addicts are lot happier with my
code.

 

[Alf P. Steinbach /Usenet]

* Krice, on 09.06.2011 12:00:

Well, if you think of it as the main usage.

It is the main usage.

It's just one option
in the list when you create a project.

Here you're talking about some IDE. I'm talking about the compiler. You are
confusing IDE and compiler; don't.

Trust me, it's perfectly
possible to write standard C++ in VS.

Given your confusion above, IDE/compiler, I would not take your word for it. But
as it happens, it's true. ;-)

Well, apart from some
rare language weirdnesses that only compile in Comeau.

Depends what you mean. MSVC support for C++0x is very partial as of MSVC 10.0.
It doesn't even complete support C++98, no matter what options you turn on.

But that's a problem also with other compilers.

In general, especially for template stuff, it's a good idea to test your code
with at least two compilers.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach /Usenet]

* Öö Tiib, on 09.06.2011 13:52:

Oh but having GUI is undefined behavior in C++. Windows itself
started like GUI framework for MS DOS originally. Since Windows NT it
became operating system. Compiler still accepts int main() and
produces applications without strange GUI-enabling switches (like /
subsystem:windows).

Without those strange-looking switches MSVC gives console subsystem by default.

Yes, you can put it that way too. Well ... lot of code works command
line. Just input something, do something, output some html or xml and
done.

Just as an example, the GNU toolchain (e.g. MinGW g++) does not have this
problem of not accepting `main`; it accepts `main` regardless of subsystem.

If there has to be interactive GUI then i somehow prefer Qt to
MS GUI and OpenGL to DirectX. Compiles and works with MSVC. Also
friendly i(something) and Linux addicts are lot happier with my
code.

That sort of misses the point. You still need to ask for GUI subsystem when you
build that app for Windows. Unless you want a console window popping up...


Cheers & hth.,

- Alf

 

[Krice]

Here you're talking about some IDE. I'm talking about the compiler.
You are confusing IDE and compiler; don't.

I think it's safe to say that VS is a IDE. I don't know if you even
can download Microsoft C++ compiler without the editor part. It may
even be possible that the compiler was not designed to run stand
alone. But some guys will no doubt try it anyway..

 

[Öö Tiib]

* Tiib, on 09.06.2011 13:52:


That sort of misses the point. You still need to ask for GUI subsystem when you
build that app for Windows. Unless you want a console window popping up....

Yes, i may want it to be there (popping up can be avoided by hiding
it), because without console the cin, cerr and cout go to god knows
where in Windows. Actually I have seen (portable to Linux and Mac)
code that has gone full round:

int main( int argc, char *argv[] ) {
Configuration::Load( argc, argv );
#if defined(_MSC_VER)
BOOL ok = ::AllocConsole();
// ... mess with screen buffers of console
// ... redirect std streams to console
#endif
return Session::run( argc, argv );
}

"Full round" in sense that they had /subsystem:windows and they had
int main() and now what was missing was console. Also the solution to
their issue was not as stupid as it feels. It sort of supports your
point, sort of argues with it and sort of misses it too. The real
reasons behind the mess are in Windows architecture, the MS compiler
team feels to consist of decent specialists.

 

[Öö Tiib]

I think it's safe to say that VS is a IDE. I don't know if you even
can download Microsoft C++ compiler without the editor part. It may
even be possible that the compiler was not designed to run stand
alone. But some guys will no doubt try it anyway..

Alf is right that you should not confuse IDE and compiler, someone may
read it and become confused as well. VS is certainly IDE but the
compiler (often called either as VC++ or MSVC) is not IDE.

You can certainly use MSVC without IDE or as integrated into some
other IDE. I have heard that even MicroSoft itself does not use the VS-
generated solutions and projects, they use makefiles for building
their own software.

If you don't know how to download MS compiler without IDE, then i can
help you:
http://www.microsoft.com/downloads/...69-9671-4330-a63e-1fd44e0e2505&displaylang=en

 

[Balog Pal]

I believe the Visual C++ creators missed the fact that in order for the
compiler to use >= with enumeration, the integral promotion [conv.prom]
should be performed (see [expr.rel]/2), and according to
[over.ics.scs]/3 an exact match (for identity category) has a higher
rank than a promotion. A clear bug.

Right !

Yep ! :-

http://connect.microsoft.com/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Ridiculous. Closed as wontfix immediately.
Anyone pays actual money for this crapware called VS? Seems it will not
change until they start to request payback. :-(

Looks even more interesting.
http://support.microsoft.com/kb/128344
suggests the problem was present in early versions of VS. And got fixed at
5.0 (I was kinda baffled about the report, as I do regularly use operator |
overloaded for enums, and can't recall problems in VS5, 6 and 2008).

So it looks a regresson for VS2010. And points to a serious defect in the
quality system too, as there should be an automatic test case for the once
fixed thing. :-(

 

[Alf P. Steinbach /Usenet]

* Krice, on 10.06.2011 08:08:

I think it's safe to say that VS is a IDE.

Yes, and it's safe to say Italy is a country. You don't make much sense. It
seems that you're again confusing IDE, where Microsoft's is now called Visual
Studio or VS, and compiler, where Microsoft's is called Visual C++, or MSVC.

I don't know if you even
can download Microsoft C++ compiler without the editor part.

Dunno. This has changed a lot, and nobody keeps much track. But the main way to
do that has been to download the compiler as part of the Windows SDK.

It may
even be possible that the compiler was not designed to run stand
alone.

You can find out about the history of this compiler by googling it. Or
Wikipedia. Please google things before asking.

However, it's not necessary to google the details of one particular compiler,
because *all* extant compilers are designed for command line usage.

The last two or five (thereabouts) years there has been a development where the
compilers additionally offer automation interfaces, for use in e.g. intellisense
like things. I think that started with the GNU preprocessor but I'm not sure.
But each such interface to the functionality is just additional, it doesn't
replace the basic command line interface.

But some guys will no doubt try it anyway..

I am sure that you would benefit a lot from doing that. It could help remove
your basic confusion about IDE and compiler. I advice you to seek help about
that in a Microsoft/Windows-specific forum though (here in clc++ we're mainly
concerned with the use of standard C++, not with tool usage and such).


Cheers & hth.,

- Alf