Best C++ compiler for Windows?



  • I haven't used C/C++ for a couple decades now.  Been mainly using Perl lately, Java before that, mostly on Linux.  I usually program in vi or notepad.  Now I need to get back into C/C++, on Windows.  I will not be requiring any graphics/gui libraries.  What do people use nowadays?  Preferably open source of course.



  • gcc from mingw sounds like an easy choice for you ... or, sometimes very helpful, clang - which IIRC is now available for windows, too.



  • If you care about open source, GCC is pretty much it... or you can look into LLVM, but that's based on GCC anyway.

    I love your "of course" as if other people give a flying shit whether it's open source or not...



  •  Thank you.  MinGW worked perfectly.



  • @blakeyrat said:

    or you can look into LLVM, but that's based on GCC anyway.

    What.



  • @Spectre said:

    @blakeyrat said:
    or you can look into LLVM, but that's based on GCC anyway.

    What.

    "The LLVM Compiler Infrastructure (based on GCC)."

    If that's wrong, don't blame me.



  • Yes and no ...

    http://llvm.org/:

    1. The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support [...]

    2. Clang is an "LLVM native" C/C++/Objective-C compiler [...]

    3. dragonegg and llvm-gcc 4.2 integrate the LLVM optimizers and code generator with the GCC [...]

    On the one hand, they took GCC and basically replaced everything except its language frontends (i.e., parsers). On the other hand, many programmers only interact with the frontend of a compiler, so ...



  • There is a simple proof that LLVM can't be based on GCC — GCC is available under the GPL, whereas LLVM uses a BSD-like license.



  • @Spectre said:

    There is a simple proof that LLVM can't be based on GCC — GCC is available under the GPL, whereas LLVM uses a BSD-like license.

    Fine! I didn't write the fucking website. No sense piling on me. Pile on them. I apologize for assuming that ATT knows anything about C++ compilers, what a stupid mistake for me to have made.



  • http://llvm.org/docs/FAQ.html#license



  • @Pascal said:

     Thank you.  MinGW worked perfectly.

    MinGW is also much better than Visual C++ when it comes to dependencies. MinGW target executables are designed to be spartan, run-anywhere entities. Visual C++, especially in its later versions, suffers from all sorts of little pitfalls related to setup and deployment
    ("manifest" files, WinSxS, uninstalled C runtime versions, etcetera). There have been times when I have fixed one of these problems by simply rebuilding using MinGW and forgetting the problem ever happened. When facing time constraints, I have even done this at hide-bound Microsoft development shops. I love the look I get when I reveal the "fix" after the fact. It's like watching a man find Valtrex in his date's medicine cabinet after a one-night stand... it's disgusting afterwards, but you sure needed it just a few hours ago ;)



  • @bridget99 said:

    Visual C++, especially in its later versions, suffers from all sorts of little pitfalls related to setup and deployment
    ("manifest" files, WinSxS, uninstalled C runtime versions, etcetera).

    Those 'little pitfalls', as you call them, are there to ensure version consistency when using dynamically linked libraries, to ensure end-users don't have to install multiple copies of the same library version and to ensure that compatible security updates can be patched into a library later. (It's the same deployment strategy used by Windows update and several Microsoft-authored libraries such as the VC++ runtimes, iirc.)

    All of those are actually good things.

    Ofcourse for all the versioning goodness to work correctly, you are required to follow Microsoft's deployment guidelines and create an installer that correctly deploys your dynamically linked libraries in the centralized side-by-side WinSxS repository with the correct manifests describing their contents. Blame C++ for not having a standardized ABI that contains this kind of data necessary for serious integrated installation / deployment strategies. Not Microsoft.



  • @Ragnax said:

    @bridget99 said:
    Visual C++, especially in its later versions, suffers from all sorts of little pitfalls related to setup and deployment
    ("manifest" files, WinSxS, uninstalled C runtime versions, etcetera).

    Those 'little pitfalls', as you call them, are there to ensure version consistency when using dynamically linked libraries, to ensure end-users don't have to install multiple copies of the same library version and to ensure that compatible security updates can be patched into a library later. (It's the same deployment strategy used by Windows update and several Microsoft-authored libraries such as the VC++ runtimes, iirc.)

    All of those are actually good things.

    Ofcourse for all the versioning goodness to work correctly, you are required to follow Microsoft's deployment guidelines and create an installer that correctly deploys your dynamically linked libraries in the centralized side-by-side WinSxS repository with the correct manifests describing their contents. Blame C++ for not having a standardized ABI that contains this kind of data necessary for serious integrated installation / deployment strategies. Not Microsoft.



    Yes, I am aware that I'm not doing things the Microsoft way. Thanks for your post clarifying that; but the "MinGW" part should be a dead giveaway on that point anyway.

    I'm not touching WinSxS. It disgusts me. WinSxS is an exercise in remorse-driven development that happened twenty years too late for any good to result. COM objects were an answer to "DLL Hell." So were .NET DLLs. I don't need a third answer, especially one that hacks around the problem with spoofing and action-at-a-distance.

    Besides that, I prefer having two systems of libraries with versioning and one without to having three systems of libraries with versioning. Static DLLs have their place. I don't necessarily care about "multiple copies of the same library version." Sometimes I care more about being certain which DLL actually get used. I'm thinking of situations where I might use static linking in a pure C++ project, but where I want to use a .NET caller, for example.

    Yeah, I could wade into a minefield of manifests and such, and do things the Microsoft way, but sometimes shit just has to get done. And I do "blame Microsoft" for some of this. Sure, there's no C++ ABI; I would suggest C++ is a tool that can be used to build ABIs. It's a systems programming language. But Microsoft had every opportunity to give us a "standardized ABI," and instead they gave us three. Maybe that's just progress. But then, Microsoft had second thoughts about one of their ABIs, and quietly finagled it into working like the other two ABIs.

    Perhaps the most amazing thing about WinSxS is how quietly this monumental change was foisted upon us. I look back with amazement at some of the people to whom I've had to explain WinSxS. You don't have to evangelize about WinSxS to me. I'm at least one step ahead of you.

    People tell me I'm the worst developer on this board. Please spare me; apparently I'm doing so much of the real work out there that I was among the first victims of WinSxS out there. And the colleagues whom I rescued from days of pointless manifest-diddling with my stealthy use of MinGW thought I was pretty brilliant.

Log in to reply