ambiguous operator on Visual Studio 2010

Discussion in 'C++' started by Aaron Gray, Jun 8, 2011.

  1. Aaron Gray

    Aaron Gray Guest

    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
     
    Aaron Gray, Jun 8, 2011
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Jun 8, 2011
    #2
    1. Advertising

  3. Aaron Gray

    Aaron Gray Guest

    "Victor Bazarov" <> wrote in message
    news:isnta6$9da$...
    > 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
     
    Aaron Gray, Jun 8, 2011
    #3
  4. Aaron Gray

    Aaron Gray Guest

    "Aaron Gray" <> wrote in message
    news:...
    > "Victor Bazarov" <> wrote in message
    > news:isnta6$9da$...
    >> 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
     
    Aaron Gray, Jun 8, 2011
    #4
  5. Aaron Gray

    Balog Pal Guest

    "Aaron Gray" <>
    >>> 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. :-(
     
    Balog Pal, Jun 8, 2011
    #5
  6. Aaron Gray

    Krice Guest

    On 8 kesä, 19:47, "Balog Pal" <> 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.
     
    Krice, Jun 8, 2011
    #6
  7. Aaron Gray

    Bo Persson Guest

    Balog Pal wrote:
    > "Aaron Gray" <>
    >>>> 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
     
    Bo Persson, Jun 8, 2011
    #7
  8. * Bo Persson, on 08.06.2011 21:29:
    > Balog Pal wrote:
    >> "Aaron Gray"<>
    >>>>> 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>
     
    Alf P. Steinbach /Usenet, Jun 8, 2011
    #8
  9. Aaron Gray

    Öö Tiib Guest

    On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > 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.
     
    Öö Tiib, Jun 9, 2011
    #9
  10. * Öö Tiib, on 09.06.2011 01:06:
    > On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    > > 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>
     
    Alf P. Steinbach /Usenet, Jun 9, 2011
    #10
  11. Aaron Gray

    Krice Guest

    On 9 kesä, 04:20, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > 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.
     
    Krice, Jun 9, 2011
    #11
  12. Aaron Gray

    Balog Pal Guest

    "Bo Persson" <>
    >> 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.
     
    Balog Pal, Jun 9, 2011
    #12
  13. Aaron Gray

    Öö Tiib Guest

    On Jun 9, 4:20 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > wrote:
    > * Öö Tiib, on 09.06.2011 01:06:
    > > On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    > > >  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. ;)
     
    Öö Tiib, Jun 9, 2011
    #13
  14. * Krice, on 09.06.2011 12:00:
    > On 9 kesä, 04:20, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    > > 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>
     
    Alf P. Steinbach /Usenet, Jun 9, 2011
    #14
  15. * Öö Tiib, on 09.06.2011 13:52:
    > On Jun 9, 4:20 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    > > wrote:
    >> * Öö Tiib, on 09.06.2011 01:06:
    >>> On Jun 8, 10:50 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    >>> > 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>
     
    Alf P. Steinbach /Usenet, Jun 9, 2011
    #15
  16. Aaron Gray

    Krice Guest

    On 9 kesä, 21:46, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > 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..
     
    Krice, Jun 10, 2011
    #16
  17. Aaron Gray

    Öö Tiib Guest

    On Jun 9, 9:51 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    > 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.
     
    Öö Tiib, Jun 10, 2011
    #17
  18. Aaron Gray

    Öö Tiib Guest

    On Jun 10, 9:08 am, Krice <> wrote:
    > On 9 kesä, 21:46, "Alf P. Steinbach /Usenet" <alf.p.steinbach
    >
    > > 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/...69-9671-4330-a63e-1fd44e0e2505&displaylang=en
     
    Öö Tiib, Jun 10, 2011
    #18
  19. Aaron Gray

    Balog Pal Guest

    "Balog Pal" <>
    > "Aaron Gray" <>
    >>>> 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. :-(
     
    Balog Pal, Jun 10, 2011
    #19
  20. * Krice, on 10.06.2011 08:08:
    > On 9 kesä, 21:46, "Alf P. Steinbach /Usenet"<alf.p.steinbach
    > > 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>
     
    Alf P. Steinbach /Usenet, Jun 10, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wh
    Replies:
    2
    Views:
    532
    Cowboy \(Gregory A. Beamer\)
    Jan 16, 2004
  2. Thirumalai
    Replies:
    0
    Views:
    677
    Thirumalai
    May 22, 2006
  3. rockdale
    Replies:
    1
    Views:
    621
    Juan T. Llibre
    Aug 23, 2006
  4. xman
    Replies:
    0
    Views:
    516
  5. Saraswati lakki
    Replies:
    0
    Views:
    1,348
    Saraswati lakki
    Jan 6, 2012
Loading...

Share This Page