Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > ambiguous operator on Visual Studio 2010

Reply
Thread Tools

ambiguous operator on Visual Studio 2010

 
 
Aaron Gray
Guest
Posts: n/a
 
      06-08-2011
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

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      06-08-2011
On 6/8/2011 9:09 AM, Aaron Gray wrote:
> 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
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
 
 
 
Aaron Gray
Guest
Posts: n/a
 
      06-08-2011
"Victor Bazarov" <(E-Mail Removed)> wrote in message
news:isnta6$9da$(E-Mail Removed)...
> On 6/8/2011 9:09 AM, Aaron Gray wrote:
>> 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 !

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

>
> I can't think of any right now.


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

Many thanks,

Aaron

 
Reply With Quote
 
Aaron Gray
Guest
Posts: n/a
 
      06-08-2011
"Aaron Gray" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Victor Bazarov" <(E-Mail Removed)> wrote in message
> news:isnta6$9da$(E-Mail Removed)...
>> On 6/8/2011 9:09 AM, Aaron Gray wrote:
>>> 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/VisualS...loading-broken

Aaron

 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      06-08-2011
"Aaron Gray" <(E-Mail Removed)>
>>> 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/VisualS...loading-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.

 
Reply With Quote
 
Krice
Guest
Posts: n/a
 
      06-08-2011
On 8 kesä, 19:47, "Balog Pal" <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      06-08-2011
Balog Pal wrote:
> "Aaron Gray" <(E-Mail Removed)>
>>>> 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/VisualS...loading-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


 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      06-08-2011
* Bo Persson, on 08.06.2011 21:29:
> Balog Pal wrote:
>> "Aaron Gray"<(E-Mail Removed)>
>>>>> 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/VisualS...loading-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)

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      06-08-2011
On Jun 8, 10:50*pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      06-09-2011
* Öö Tiib, on 09.06.2011 01:06:
> On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> (E-Mail Removed)> wrote:
>> 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.


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

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Share-Point-2010 ,Share-Point -2010 Training , Share-point-2010Hyderabad , Share-point-2010 Institute Saraswati lakki ASP .Net 0 01-06-2012 06:39 AM
CFP with Extended Deadline of Mar. 31, 2010: The 2010 InternationalConference on Modeling, Simulation, and Visualization Methods (MSV'10), USA,July 2010 A. M. G. Solo VHDL 0 03-25-2010 12:04 PM
T::operator int () const ambiguous with T::operator Handle () const? Tim Clacy C++ 15 05-30-2005 02:14 AM
operator*(Foo) and operator*(int) const: ISO C++ says that these are ambiguous: Alex Vinokur C++ 4 11-26-2004 11:46 PM
visual studio .net 2003 verses visual studio .net 2002 wh ASP .Net 2 01-16-2004 04:54 PM



Advertisments