Announcement

Collapse
No announcement yet.

Apache Kills Off Its C++ Standard Library

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Microsoft has made it very clear in at least one MSDN posting that they have near zero interest in supporting C99 as they want to push people to C++.

    And MSVC is in very good shape for C++11 support where proprietary compilers are concerned.

    Comment


    • #22
      Originally posted by mrugiero View Post
      I'm using 2012, since AFAIK 2013 is still kind of beta.
      It sounds like the 2013 preview is somewhere between a beta and a release candidate. They released it with full support, which isn't something the VS team normally does with previews. I don't have much personal experience with it yet, though, so don't take my word on it.

      I'm considering moving our team to 2013, because I was impressed with last November's preview, and it's definitely come a long way in C++11 support. However, based on Herb Sutter's Build talk, I don't think the C99 features you want are in the preview release; sounds like you'll have to wait for the full release to get those.

      Comment


      • #23
        Originally posted by Sonadow View Post
        Microsoft has made it very clear in at least one MSDN posting that they have near zero interest in supporting C99 as they want to push people to C++.
        They didn't make it clear enough, since they still blame their users for not pushing enough for that. Also, I don't deny its capabilities as a C++ compiler, but if you'll blatantly say "you should go C++ and quit C", then just drop C support altogether, and make my life easier by making me able to say "not my fault, MSVC doesn't like C, just go with MinGW, guys".

        Originally posted by Skrapion View Post
        It sounds like the 2013 preview is somewhere between a beta and a release candidate. They released it with full support, which isn't something the VS team normally does with previews. I don't have much personal experience with it yet, though, so don't take my word on it.

        I'm considering moving our team to 2013, because I was impressed with last November's preview, and it's definitely come a long way in C++11 support. However, based on Herb Sutter's Build talk, I don't think the C99 features you want are in the preview release; sounds like you'll have to wait for the full release to get those.
        I'll wait and see. If they're there, then great, I don't require anything more advanced right now, and it seems to have pretty good tools.
        Restrict keyword would also be good, but is not a must.
        Last edited by mrugiero; 20 July 2013, 03:08 AM.

        Comment


        • #24
          Originally posted by Sonadow View Post
          And of all the proprietary compilers in the list, Microsoft's compiler offered the best support for C++11, implementing features that Intel's own compiler still lacked support for. Explain how that equates to Microsoft not taking C++11 seriously.
          Citation needed. Look at http://msdn.microsoft.com/en-us/libr.../hh567368.aspx : MSVC does not support some of the KEY features of c++11, namely: variadic templates, constexpr, initializer lists (and lots of others which I don't use every day).

          Compare that to gcc or clang which supported most features as they were being finalized, and are now feature-complete. I know, those are not commercial compilers, but you say basically that MSVC is the one-eyed among blinds; and don't mention that gcc and clang are there already.

          Comment


          • #25
            Originally posted by eudoxos View Post
            Citation needed. Look at http://msdn.microsoft.com/en-us/libr.../hh567368.aspx : MSVC does not support some of the KEY features of c++11, namely: variadic templates, constexpr, initializer lists (and lots of others which I don't use every day).
            Citation provided!

            The page you were looking at does not include the latest updates. The November CTP includes variadic templates and initializer lists, and has since been replaced by the Visual Studio 2013 preview, which is supported by Microsoft. constexpr is still missing, and not the highest priority on their list, but is expected in an out-of-band preview some time between Visual Studio 2013 and the next version. Herb Sutter's Build talk is the best place for this information at the moment.

            Comment


            • #26
              Originally posted by Skrapion View Post
              Citation provided!The page you were looking at does not include the latest updates.
              Thanks for the link. What I see: commercial compiler backed by a rather strong company is 1 year behind open-source compilers. Not impressed at all.

              It is not surprising windows devs run away from msvc and grab mingw, as it is not in a very good shape with mingw-w64.

              Comment


              • #27
                Originally posted by eudoxos View Post
                Thanks for the link. What I see: commercial compiler backed by a rather strong company is 1 year behind open-source compilers. Not impressed at all.

                It is not surprising windows devs run away from msvc and grab mingw, as it is not in a very good shape with mingw-w64.
                Citation needed. I still haven't seen anyone running away from msvc, in fact I've seen the reverse where people decide mingw is no longer worth it.

                I really don't think MS cares about whether you're impressed with their compiler or not. The main benefit is in all the tools they provide, and being 1 year back in new features isn't that big of a deal. GCC is 1 year back of LLVM in various things, LLVM is 1 year behind GCC in various things, and so on... MSVC provides the best integration into the windows OS, which is why windows developers overwhelmingly choose to use it. Debian stable just updated from GCC 4.4 to 4.7, so it's still quite a bit behind the latest and greatest even on the OSS side.
                Last edited by smitty3268; 04 August 2013, 04:35 PM.

                Comment


                • #28
                  Originally posted by smitty3268 View Post
                  I still haven't seen anyone running away from msvc, in fact I've seen the reverse where people decide mingw is no longer worth it.

                  I really don't think MS cares about whether you're impressed with their compiler or not. The main benefit is in all the tools they provide, and being 1 year back in new features isn't that big of a deal. GCC is 1 year back of LLVM in various things, LLVM is 1 year behind GCC in various things, and so on... MSVC provides the best integration into the windows OS, which is why windows developers overwhelmingly choose to use it. Debian stable just updated from GCC 4.4 to 4.7, so it's still quite a bit behind the latest and greatest even on the OSS side.
                  I can cite myself; also, qt5 is newly providing official mingw builds (presumably because more people want it, right?), python is getting fixed to be (cross-)buildable with mingw. I am developing cross-platform code (under Linux, ocasionally compiling under Windows for some customers), so Windows integration is actually an obstacle; unless you are pure-Windows developer, which I fail to see the point of nowadays. Once you get used to a decent compiler, why be backwards and use msvc...

                  For you 1 year may not big deal, for me it was (especially with c++11, which was for my needs sufficiently supported already with gcc 4.5 /4.6). I think it is a shame that MSVC cannot have the compiler ready at the day c++11 went official - it was YEARS under discussion and MS guys were one of those on the board (Herb Sutter, for instance).

                  Debian always has packages for newer compilers as they appear (unstable even of their snapshots, mingw-w64 follow gcc releases with the delay of a few days), and their versions are ABI-compatible with each other (various version of gcc with various versions of clang) - whereas (IIRC) MSVC dlls link against different runtime msvcr* depending on version, and funny things happen when you load multiple msvcr* dlls at once (crash is the best thing, several versions of environment variables is less obvious). Call that great integration into Windows OS because it as messy as the OS. No, thanks, not impressed and glad to not have to use *that*.

                  Comment

                  Working...
                  X