Popular Industrial C++ Compiler for Windows
I've been using GNU g++ compiler on Ubuntu so far without any issues but now I'm switching to Windows 10 and I'm shocked that no bare version of g++ is available for Windows! There are only things like MinGw and CygWin(to be linux-like) but I'm afraid of forming bad habits. It just bewilders me that you can't use the latest standard of the famous g++ compiler on Windows straightly! Why is that so? Do you recommend me to switch back to Ubuntu?!
P.S.:
1_ I don't want to use Visual Studio because I think using command line compilers is a better habit.
2_ I couldn't find any understandable explanations to this problem neither on the official GNU website nor on anywhere else(e.g. StackOverflow, Quora, etc.)
P.S.:
1_ I don't want to use Visual Studio because I think using command line compilers is a better habit.
2_ I couldn't find any understandable explanations to this problem neither on the official GNU website nor on anywhere else(e.g. StackOverflow, Quora, etc.)
Last edited on
Not sure what you mean by "no bare version of g++ is available for Windows!"
I use g++ from the command line all the time in Windows. I have several good editors so I feel in no need of the bloat or phenomenally unnecessary load time that comes with an IDE, especially Visual Studio. Occasionally as a cross-check I use the C++ compiler within Visual Studio (cl.exe) - but I simply run it from the command line, without loading VS (just make sure you set your PATH environment variable to find the relevant files). If I have complicated compile or link commands I simply put them in a batch file. Or one could use the make facilities.
I use MinGW only to download pre-compiled binaries for g++ (and other gnu tools, libraries and compilers, like gfortran) and sort out dependencies - but that is all. It's not an IDE or environment. You would probably have a similar tool on Ubuntu linux for packages.
I can't advise you on Windows 10. What I've seen of it does not inspire me to change from a very tidy Windows 7.
I use g++ from the command line all the time in Windows. I have several good editors so I feel in no need of the bloat or phenomenally unnecessary load time that comes with an IDE, especially Visual Studio. Occasionally as a cross-check I use the C++ compiler within Visual Studio (cl.exe) - but I simply run it from the command line, without loading VS (just make sure you set your PATH environment variable to find the relevant files). If I have complicated compile or link commands I simply put them in a batch file. Or one could use the make facilities.
I use MinGW only to download pre-compiled binaries for g++ (and other gnu tools, libraries and compilers, like gfortran) and sort out dependencies - but that is all. It's not an IDE or environment. You would probably have a similar tool on Ubuntu linux for packages.
I can't advise you on Windows 10. What I've seen of it does not inspire me to change from a very tidy Windows 7.
Last edited on
closed account (1vRz3TCk)
| mojtabaavahdati wrote: |
|---|
| 1_ I don't want to use Visual Studio because I think using command line compilers is a better habit. |
VS is always an option...
https://docs.microsoft.com/en-us/cpp/build/walkthrough-compiling-a-native-cpp-program-on-the-command-line
Thanks for both answers, but will the commands be the same as in g++ if I use VS command line or cl.exe or I should memorize a whole new set of commands special to it?
...and I wonder if these are really what people in the industry do as well !? Well all these ways seem to be a little too much cryptic, to be honest!
...and I wonder if these are really what people in the industry do as well !? Well all these ways seem to be a little too much cryptic, to be honest!
Last edited on
For g++, give or take some executable file names, the commands that I use seem to be the same on unix or Windows.
If you are just using a basic compile from the Windows command line then
g++ test.cpp (producing a.exe by default, though you can change this with -o)
maps to
cl test.cpp (producing test.exe by default)
They even produce mutually readable binary output files.
If you want commands for special optimisations, debuggers etc, then they are slightly different, but there aren't that many that you are likely to use and there does exist documentation.
g++ (via MinGW) is a substantially smaller install!
I can't advise you on "what people in industry do" as I work in academia and (heresy, I know!) code mainly in Fortran for big projects at work.
If you are just using a basic compile from the Windows command line then
g++ test.cpp (producing a.exe by default, though you can change this with -o)
maps to
cl test.cpp (producing test.exe by default)
They even produce mutually readable binary output files.
If you want commands for special optimisations, debuggers etc, then they are slightly different, but there aren't that many that you are likely to use and there does exist documentation.
g++ (via MinGW) is a substantially smaller install!
I can't advise you on "what people in industry do" as I work in academia and (heresy, I know!) code mainly in Fortran for big projects at work.
Last edited on
Cygwin will give you a pseudo unix environment and g++ in windows. There are others. You can also use a dual boot or VM. Many avoid Cygwin, it isn't the best, but the commandline tools that integrate right into windows command line (edit the path, avoid their bash shell thingy) is pure gold.
Command line is NOT a "better habit". Just because the language was created in the 1970s is no reason to remain stuck there trying to muddle with makefiles and VI. We have modern tools, why not take advantage of 40 years of progress? It is important to understand the command line tools a bit (I have often found myself with an account on a machine where all I had was terminal access and g++ / nano or the like) so you can use them if you must, but you should not ONLY use them.
Command line is NOT a "better habit". Just because the language was created in the 1970s is no reason to remain stuck there trying to muddle with makefiles and VI. We have modern tools, why not take advantage of 40 years of progress? It is important to understand the command line tools a bit (I have often found myself with an account on a machine where all I had was terminal access and g++ / nano or the like) so you can use them if you must, but you should not ONLY use them.
Last edited on
Well it baffles me that Photoshop(!!!) is made using C++ and I see myself getting stuck in such silly problems yet!
Last edited on
closed account (1vRz3TCk)
| mojtabaavahdati wrote: |
|---|
| Well all these ways seem to be a little too much cryptic, to be honest! |
@CodeMonkey I'm not a fan of using IDEs, I'm against it, indeed. But I think even if I'm going to use a CL method I should conform a standard/convention that is used by a probably large group of people out there so that I can communicate with them in case that I encounter problems. That's why I'm searching for "Popular" and "Industrial" methods.
> I'm shocked that no bare version of g++ is available for Windows!
Pre-built g++ 7.2.0 (x-64 native, Windows) can be downloaded from here:
https://nuwen.net/mingw.html
Chances that this is a more current version of g++ than what you have been using on Ubuntu are high.
STL's advice is sound:
Add 'Clang with Microsoft Codegen' to Visual Studio, and you can test your code with all three mainstream compilers.
Pre-built g++ 7.2.0 (x-64 native, Windows) can be downloaded from here:
https://nuwen.net/mingw.html
Chances that this is a more current version of g++ than what you have been using on Ubuntu are high.
STL's advice is sound:
| I recommend that anyone who is learning Standard C++ and who uses Windows for a primary development environment should use two compilers: the most modern version of Microsoft Visual C++ (currently 2017) and the most modern version of GCC, the GNU Compiler Collection. Using two compilers that conform closely to the Standard subjects your code to more strenuous trials than using a single compiler would. |
Add 'Clang with Microsoft Codegen' to Visual Studio, and you can test your code with all three mainstream compilers.
JLBorges +1
OP sounds like he's making an "I hate Macs because they don't work like Windows" kind of argument.
I use the Windows command shell ALL THE TIME.
I also use ConEmu+Clink a lot.
I sometimes even use MSYS2.
All of them have their unique characteristics that makes using them interesting.
Because Windows has so many options for a C++ compiler, heck, even multiple versions of the same compiler, the thing you must learn to do on Windows is manage your %PATH%.
C and C++ compilers I currently have installed:
* MSVC 2015
* TDM-GCC-64
* Clang
* (A hardlink to TDM-GCC-64 at C:\mingw64 so that Clang will work with it)
* (I think I have a GCC buried deep in the recesses of Strawberry Perl, too.)
Using each one requires some %PATH% management:
* MSVC: use
* TDM-GCC-64: put
* Clang + MSVC 32-bit: initialize MSVC32 then put
* Clang + MSVC 64-bit: initialize MSVC64 then put
* Clang + TDM-GCC-64: put TDM-GCC-64 at the head of the path, then put the appropriate 32-or-64-bit Clang at the head of the path.
an aside
Once done, I only need to know how to frob the compiler correctly. Examples:
*
*
*
*
And so on. Notice how usage number two is exactly the same as it would be on a Linux system.
...That said, you are compiling for a completely different system. Shared libraries, for example, work differently between Linux and Windows, which means I need to frob the compiler a little differently on Windows than I would on Linux.
So, different systems? Yes, then you will have to do a few things differently.
(I would recommend CMake, but I hate it. You might still find life a bit easier if you use it, though.)
My $0.02.
OP sounds like he's making an "I hate Macs because they don't work like Windows" kind of argument.
I use the Windows command shell ALL THE TIME.
I also use ConEmu+Clink a lot.
I sometimes even use MSYS2.
All of them have their unique characteristics that makes using them interesting.
Because Windows has so many options for a C++ compiler, heck, even multiple versions of the same compiler, the thing you must learn to do on Windows is manage your %PATH%.
C and C++ compilers I currently have installed:
* MSVC 2015
* TDM-GCC-64
* Clang
* (A hardlink to TDM-GCC-64 at C:\mingw64 so that Clang will work with it)
* (I think I have a GCC buried deep in the recesses of Strawberry Perl, too.)
Using each one requires some %PATH% management:
* MSVC: use
vcvarsall.bat 32 or vcvarsall.bat 64 to initialize the PATH* TDM-GCC-64: put
C:\TDM-GCC-64\bin at the head of the path* Clang + MSVC 32-bit: initialize MSVC32 then put
C:\Program Files (x86)\LLVM\bin at the head of the PATH* Clang + MSVC 64-bit: initialize MSVC64 then put
C:\Program Files\LLVM\bin at the head of the PATH* Clang + TDM-GCC-64: put TDM-GCC-64 at the head of the path, then put the appropriate 32-or-64-bit Clang at the head of the path.
an aside
| I keep a number of little batch scripts around for the very purpose of path management. From my daily point of view, I just type the compiler name and it adjusts the path automatically. |
Once done, I only need to know how to frob the compiler correctly. Examples:
*
cl /EHsc /O3 quux.cpp*
g++ -Wall -std=c++14 -pedantic -s -m32 quux.cpp*
clang-cl /EHsc /O3 quux.cpp*
clang++ -Wall -std=c++14 -pedantic -s -m32 quux.cppAnd so on. Notice how usage number two is exactly the same as it would be on a Linux system.
...That said, you are compiling for a completely different system. Shared libraries, for example, work differently between Linux and Windows, which means I need to frob the compiler a little differently on Windows than I would on Linux.
So, different systems? Yes, then you will have to do a few things differently.
(I would recommend CMake, but I hate it. You might still find life a bit easier if you use it, though.)
My $0.02.
Thank you everybody, I finally made it. I downloaded the GCC 7.2.0 from the link provided by JLBorges and then set my system variable to the bin folder inside MinGW folder and then checked my compiler in CMD with
command and it seems that everything's fine now. I'm so happy and I appreciate all your invaluable helps.
g++ --versioncommand and it seems that everything's fine now. I'm so happy and I appreciate all your invaluable helps.
Last edited on
Topic archived. No new replies allowed.