Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #6420 > unrolled thread

ambiguous operator on Visual Studio 2010

Back to article view | Back to comp.lang.c++

Contents

  ambiguous operator on Visual Studio 2010 "Aaron Gray" <ang.usenet@gmail.com> - 2011-06-08 14:09 +0100
    Re: ambiguous operator on Visual Studio 2010 Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-08 09:26 -0400
      Re: ambiguous operator on Visual Studio 2010 "Aaron Gray" <ang.usenet@gmail.com> - 2011-06-08 14:58 +0100
        Re: ambiguous operator on Visual Studio 2010 "Aaron Gray" <ang.usenet@gmail.com> - 2011-06-08 17:22 +0100
          Re: ambiguous operator on Visual Studio 2010 "Balog Pal" <pasa@lib.hu> - 2011-06-08 18:47 +0200
            Re: ambiguous operator on Visual Studio 2010 Krice <paulkp@mbnet.fi> - 2011-06-08 11:40 -0700
            Re: ambiguous operator on Visual Studio 2010 "Bo Persson" <bop@gmb.dk> - 2011-06-08 21:29 +0200
              Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-08 21:50 +0200
                Re: ambiguous operator on Visual Studio 2010 Öö Tiib <ootiib@hot.ee> - 2011-06-08 16:06 -0700
                  Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-09 03:20 +0200
                    Re: ambiguous operator on Visual Studio 2010 Krice <paulkp@mbnet.fi> - 2011-06-09 03:00 -0700
                      Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-09 20:46 +0200
                        Re: ambiguous operator on Visual Studio 2010 Krice <paulkp@mbnet.fi> - 2011-06-09 23:08 -0700
                          Re: ambiguous operator on Visual Studio 2010 Öö Tiib <ootiib@hot.ee> - 2011-06-10 02:33 -0700
                          Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-10 12:26 +0200
                    Re: ambiguous operator on Visual Studio 2010 Öö Tiib <ootiib@hot.ee> - 2011-06-09 04:52 -0700
                      Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-09 20:51 +0200
                        Re: ambiguous operator on Visual Studio 2010 Öö Tiib <ootiib@hot.ee> - 2011-06-10 01:58 -0700
                          Re: ambiguous operator on Visual Studio 2010 "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-10 12:36 +0200
              Re: ambiguous operator on Visual Studio 2010 "Balog Pal" <pasa@lib.hu> - 2011-06-09 13:32 +0200
            Re: ambiguous operator on Visual Studio 2010 "Balog Pal" <pasa@lib.hu> - 2011-06-10 12:24 +0200

Page 1 of 2  [1] 2  Next page →

#6420 — ambiguous operator on Visual Studio 2010

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

[toc] | [next] | [standalone]

#6422

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

[toc] | [prev] | [next] | [standalone]

#6423

"Victor Bazarov" <v.bazarov@comcast.invalid> wrote in message 
news:isnta6$9da$1@dont-email.me...
> 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

[toc] | [prev] | [next] | [standalone]

#6429

"Aaron Gray" <ang.usenet@gmail.com> wrote in message 
news:959dg6FhmcU1@mid.individual.net...
> "Victor Bazarov" <v.bazarov@comcast.invalid> wrote in message 
> news:isnta6$9da$1@dont-email.me...
>> 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/VisualStudio/feedback/details/529700/enum-operator-overloading-broken

Aaron

[toc] | [prev] | [next] | [standalone]

#6431

"Aaron Gray" <ang.usenet@gmail.com>
>>> 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. :-( 

[toc] | [prev] | [next] | [standalone]

#6434

On 8 kesä, 19:47, "Balog Pal" <p...@lib.hu> 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.

[toc] | [prev] | [next] | [standalone]

#6438

Balog Pal wrote:
> "Aaron Gray" <ang.usenet@gmail.com>
>>>> 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

[toc] | [prev] | [next] | [standalone]

#6439

* Bo Persson, on 08.06.2011 21:29:
> Balog Pal wrote:
>> "Aaron Gray"<ang.usenet@gmail.com>
>>>>> 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)

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

[toc] | [prev] | [next] | [standalone]

#6454

On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#6464

* Öö Tiib, on 09.06.2011 01:06:
> On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  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>

[toc] | [prev] | [next] | [standalone]

#6477

On 9 kesä, 04:20, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#6514

* Krice, on 09.06.2011 12:00:
> On 9 kesä, 04:20, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> 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 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

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

[toc] | [prev] | [next] | [standalone]

#6529

On 9 kesä, 21:46, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> 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..

[toc] | [prev] | [next] | [standalone]

#6533

On Jun 10, 9:08 am, Krice <pau...@mbnet.fi> wrote:
> On 9 kesä, 21:46, "Alf P. Steinbach /Usenet" <alf.p.steinbach
>
> +use...@gmail.com> wrote:
> > 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..

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/en/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505&displaylang=en

[toc] | [prev] | [next] | [standalone]

#6538

* Krice, on 10.06.2011 08:08:
> On 9 kesä, 21:46, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> 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.

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

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

[toc] | [prev] | [next] | [standalone]

#6482

On Jun 9, 4:20 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Öö Tiib, on 09.06.2011 01:06:
> > On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> > +use...@gmail.com>  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.
> > ...
> > 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.

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. ;)

[toc] | [prev] | [next] | [standalone]

#6515

* Öö Tiib, on 09.06.2011 13:52:
> On Jun 9, 4:20 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> * Öö Tiib, on 09.06.2011 01:06:
>>> On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
>>> +use...@gmail.com>    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.
>>> ...
>>> 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.
>
> 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.


>> 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.

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

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

[toc] | [prev] | [next] | [standalone]

#6532

On Jun 9, 9:51 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Tiib, on 09.06.2011 13:52:
>
> > 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...

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.

[toc] | [prev] | [next] | [standalone]

#6541

* Öö Tiib, on 10.06.2011 10:58:
> On Jun 9, 9:51 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> * Tiib, on 09.06.2011 13:52:
>>
>>> 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...
>
> Yes, i may want it to be there (popping up can be avoided by hiding
> it),

Ah.


> because without console the cin, cerr and cout go to god knows
> where in Windows.

Well, in addition to God, you might ask me. :-) By default they go nowhere. But 
they can be redirected, by the ordinary redirection operators.


> 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();

"If the compiler is MSVC, allocate a console window". Hm. You better inform 
those folks that they're doing meaningless things.


>       // ... 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.

That's my preference. An ordinary GUI subsystem app, with a standard `main`. Why 
write more to get non-standard code? That's just silly. It's like writing `void 
main`, one character more, just to get a non-standard idiot's[1] version.


> 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.

There's no mess wrt. this in the Windows architecture.

To wit, the MinGW g++ compiler / toolchain does not have this problem.

Technical: `main` and `wMain` and `winMain` and `wWinMain` are not supported at 
the Windows API level (disregarding the MSVC runtime as part of the API).


Cheers & hth.,

- Alf

Notes:
[1] When I'm writing "idiot's" that's just an exaggeration to put it to a point. 
For example, Bjarne used that `void main` at least once in the second edition of 
The C++ Programming Language, and I'm not calling him an idiot. :-)

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

[toc] | [prev] | [next] | [standalone]

#6481

"Bo Persson" <bop@gmb.dk>
>> 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?

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. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web