I like the Visual Studio IDE. I'm used to it and find it is the best IDE I've ever tried. We also find increasing use of C#/.NET here.
However, after the underwhelming announcement regarding C++11 features in VS11 I'm looking into replacing the compiler.
It seems that the Intel compiler fully integrates with VS but that doesn't mean it will compile our Windows code. I don't know how I'd fare with a try of g++ or clang
Can VS actually be productively used with a different C++ compiler to compile Windows code, that is legacy code using all kinds of Win32 / MFC / COM stuff?
Depends on how much use you made of the Microsoft-proprietary extensions. Things like #pragma once tend to be supported by all the major compilers, but the weirder COM things (e.g., #import and anything C++/CLI) probably won't be. No idea if MFC will build under the new compiler, but you'll probably have to link it statically or ship your own DLL; G++ definitely uses a different mangling scheme than MSVC.
I'm not sure how easy it is to replace cl.exe and keep your vcproj files intact (though some compilers actually do it), but there are always Makefile projects.
I have never actually worked with the Intel C++ compiler, but I see no reason why it wouldn't compile the code that VC++ does. Here is official Intel documentation.
I use Visual Studio 2008 with a Makefile project to cross-compile; no reason you couldn't do the same with a different Windows compiler.
Related
Say I have a open source C::B C++ (non-C++11, perfectly compatible with the 1998 ISO standard) project I've downloaded which is using MinGW/GCC (TDM-1 4.7.1 or 4.7.2 - doesn't work with newest version),; can I port the source files from it to Visual Studio 2010 and be able to make it work without massive code rewriting? Or there are certain cases in which it won't be possible? Or it depends on various things?
EDIT:
The code relies on additional external utilities and libraries such as:
Lua
SDL 2.0 + SDL Image 2.0
OpenGL
The most General and correct response is: It depends on various things.
What kind of project are you refering to? Is it wxWidget, QT4, GTK+, OpenGL?
How much do you use c++11?
Assuming that we are talking about a simple Console Application the easiest way to verify whether you can migrate to MSVC2010 is to switch compiler inside Code::Blocks project.
Select Project->Build Option... and under Selected compiler choose Microsoft Visual Studio C++ 2010. Afterwards try to recompile. The warning and errors will show you how easy will be the porting.
Of course you have to install Code::Blocks with MSVC2010 too.
EDIT: The OpenGL library is supported by MSVC2010 and libsdl has VC development libraries. However, things seem to be more complex with Lua. My guess is that you might start a substantial porting work here.
If the project was written using portable C++98 code you shouldn't have too much trouble. First, I would check you can compile in GCC with -std=c++98 -pedantic flags and fix any warnings to ensure you are not relying on any GCC extensions.
It also depends on the portability of any required libraries.
Try it!
If your code is standard-compliant and does not rely on any GCC extensions or GCC-specific libraries, then you should be fine out-of-the-box.
Note though that different compilers support C++ in different ways; for example, even Visual Studio 2013 has only passing C++11 support so if your program is a C++11 program with things like ranged-for and initializer lists in it then, depending on the version you're using, it's just not going to work without those pieces of code being rewritten to look more like C++03.
I actually made a mistake:
C::B indeed told me there were multiple errors in the compilation attempt with the MSVC2010 compiler, because the code included many Unix-only libraries, too intricately so to be easily avoided. Thus, I'm thinking of either making MinGW/GCC work in Visual Studio itself or sticking with C::B.
(Continues here: POSIX Headers (from MinGW project) in Visual Studio 2013)
I am writing code in VS that should be ported later to Linux. I found that sometimes, I may use some functions or code that is available only on Windows and not on Linux.
Is there any way that I can set my Visual Studio to report me these non portable pieces of code?
I prefer to use VS during development and then use the code base and compile it in Linux.
You can treat MinGW as a reference compiler, just to check whether the code you write is portable.
You can also disable MSVC compiler extensions in the compiler options settings in Project Properties (or set /Za flag). That will most likely make at least <windows.h> stop compiling.
Frankly, though, I don't see a problem in simply not using nonportable things. Stick to standard library and libraries that you know are portable and you're good to go. (granted, syntactic extensions are easier to accidentally use, but then again their usages are also typically trivial to put back in proper way).
Some open source projects explicitly state that in order to compile on windows, they need a microsoft compiler (often a specific version as well, as latter versions are incompatible or will refuse to compile older code).
Since it seems absurd to me that, since there are foss compilers that can compile for windows, a microsoft compiler would be necessary for any fundamental task, I'm assuming this is because those projects use api calls to libraries (such as msvcrt*.dll) that, for some reason, mingw-gcc, clang and other ports of compilers for windows are unable to compile against.
My understanding of these requirements is shallow, since my experience with compiled code comes primarily from linux and this worries me, since getting a microsoft compiler is non-trivial. the only way to get them is through the express editions of microsoft's visual c++, and even then, the most recent version will completely refuse to install on an old winxp machine like mine and the only version available at the moment is vc++express2010, which requires registrations to turn from trialware into freeware (and even then i'm not clear on if that'll work or what it entails - perhaps OS hooks to "debug" and other intereference?).
1) My question is, do these projects depend on microsoft compilers due to building against these microsoft-only libraries (which apparently foss compilers can't do)?
It would seem absurd if the reason is the build script or preprocessor directives, since those can be relatively easily ported.
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc. calls, i can still find myself needing a microsoft compiler to compile native windows software (assuming no usage of libraries that do perform those calls)?
3) Can I simply use clang and some widget library to make native windows software just as well?
4) Can I modify the source of a project so that it doesn't depend on a microsoft compiler?
(ok that's 4 questions, sorry, this is quite hard for me to express clearly).
1) My question is, do these projects depend on microsoft compilers due
to building against these microsoft-only libraries (which apparently
foss compilers can't do)?
Compiler vendors and GUI framework vendors can supply DLLs that perform similar to the MS DLLs. Some of the MS DLLs are system DLLs and are used by the other compiler and framework vendors.
If you are using compiler or framework specific DLLs, they need to accompany the installation of your programs (projects).
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc.
calls, i can still find myself needing a microsoft compiler to compile
native windows software (assuming no usage of libraries that do
perform those calls)?
No. If you scan through the posts on StackOverflow, there are many people who are using the Windows API directly, I guess what you are calling native windows software. Usually, the code for these API are located in a system API. The compiler translates the function call to a call into these DLLs, loading them as necessary.
3) Can I simply use clang and some widget library to make native
windows software just as well?
No, you can't. That's why they exist.
Again, many people are using frameworks like Qt and xWidgets without the MS compilers. I did that for a while. I switched over to Visual Studio, primarily for the debugger. I didn't like how other IDEs tried to use GDB. Otherwise, I wouldn't use MS because they tend to go by the Microsoft Standard language rather than the ISO.
4) Can I modify the source of a project so that it doesn't depend on a
microsoft compiler?
No, that is why there are freeware and other compilers out there.
Hmmm, one can use Java to create GUIs that don't use the MS compiler, but they use the Windows API.
Try installing Cygwin. When you look at all the libraries you will realize that projects can be created that don't use the MS Compiler. Again, read through the StackOverflow posts and you will find that people are using other compilers, such as Intel, GNU, Clang, Greenhills and others. Some compilers for embedded systems will also compile for Windows OS, so you can write code that works on both platforms.
Looks like you need to search the web for "GNU GUI tutorial C++" and see what pops up. Also, search for "wxWidgets" and "Qt" for other frameworks.
I have developed some code under Unix using Cgwin, Linux and HP-UX. Since I don't want to start from scratch when doing some Windows stuff, I wanted to compile the code with Visual Studio 2008. Of course I'm aware that I have to do some adaptions, regarding system specific functionality like using fcntl. What I didn not expect though, was that there seem to be also problems using standard functions like snprintf etc.
snprintf and Visual Studio 2010 or
Error 4 error C3861: 'snprintf': identifier not found
Since there are also many other problems, I was considering using MingW. As far as I understood, MingW is a native Windows compiler right? So I still would have to port the systerm specific stuff, but I would like to know, if the move to MingW would give me any benefit by reducing the number of compatibillity issues.
I'm aware that this might be regarded as opnion based, but I don't want to compare MingW vs. MSVC, I just would like to know if the switch would reduce the porting issues, or if it is as waste of time and just as well stick to MSVC. I have ported code before, but always from Windows to Unix, which seems to have been much easier then the other way around.
As far as I understood, MingW is a native Windows compiler right?
If by native you meant Windows as a target OS, then yes. But if you were thinking about the building host - If you want so. MinGW is a GCC port, and can be built for Linux as well. Latest Ubuntu has both x32 and x64 versions of MinGW, for example.
I would like to know, if the move to MingW would give me any benefit
by reducing the number of compatibillity issues.
Definitely yes. Using GCC port means you will need to solve only OS-dependent issues, and skip compiler and Microsoft library differences.
I currently develop in C++ on Windows, using Visual Studio 2010. After the official announcement of C++11, I have begun to use some of its features that are already available in MSVC. But, as expected, the great majority of the new changes are not supported.
I thought maybe the upcoming version of Visual Studio would add these new features. However, after reading this it looks like very little is going to change.
And so, I'm curious about the feasibility of using GCC on Windows rather than MSVC, as it appears to support the great majority of C++11 already. As far as I can tell, this would mean using MinGW (I haven't seen any other native Windows versions of GCC). But I have questions about whether this would be worth trying:
Can it be used as a drop-in replacement for cl.exe, or would it involve a lot of hacks and compatibility issues to get Visual Studio to use a different compiler?
The main selling point for Visual Studio, in my opinion, is it's debugger. Is that still usable if you use a different compiler?
Since GCC comes from the *nix world, and isn't native to Windows, are there code quality issues with creating native Windows applications, versus using the native MSVC compiler? (If it matters: most of my projects are games.)
In other words, will the quality of my compiled exe's suffer from using a non-Windows-native compiler?
MSVC has the huge advantage of coming with an IDE that has no equals under Windows, including debugger support.
The probably best alternative for MinGW would be Code::Blocks, but there are worlds in between, especially regarding code completion and the debugger.
Also, MSVC lets you use some proprietary Microsoft stuff (MFC, ATL, and possibly others) that MinGW has no support for, and makes using GDI+ and DirectX easier and more straightforward (though it is possible to do both with MinGW).
Cygwin, as mentioned in another post, will have extra dependencies and possible license issues (the dependency is GPL, so your programs must be, too). MinGW does not have any such dependency or issue.
MinGW also compiles significantly slower than MSVC (though precompiled headers help a little).
Despite all that, GCC/MinGW is an entirely reliable quality compiler, which in my opinion outperforms any to date available version of MSVC in terms of quality of generated code.
This is somewhat less pronounced with the most recent versions of MSVC, but still visible. Especially for anything related to SSE, intrinsics, and inline assembly, GCC has been totally anihilating MSVC ever since (though they're slowly catching up).
Standards compliance is a lot better in GCC too, which can be a double-edged sword (because it can mean that some of your code won't compile on the more conforming compiler!), as is C++11 support.
MinGW optionally also supports DW2 exceptions, which are totally incompatible with the "normal" flavour and take more space in the executable, but on the positive side are "practically zero cost" in runtime.
I want to add some information because the field may have changed since the question was asked.
The main problem for switching away from MSVC was the lack of a good IDE that flawlessly integrates with MinGW . Visual Studio is a very powerful tool and was the only player on Windows for quite some time. However, Jetbrains released a preview version of their new C++ IDE CLion some days ago.
The main benefit comes when working on cross platform applications. In this case, a GCC based tool chain can make life much easier. Moreover, CLion narrowly integrates with CMake, which is also a big plus compared to Visual Studio. Therefore, in my opinion, it is worth to consider switching to MinGW now.
GCC's C++11 support is quite phenomenal (and quite up to par with standards conformance, now that <regex> has been implemented).
If you replace your compiler, you'll need to make sure every dependency can be built with that new compiler. They're not made to be substitutable plugins (although Clang is working on becoming that way).
GCC is a fine compiler, and can produce code that has pretty much the same performance, if not better, than MSVC. It is missing some low-level Windows-specific features though.
Apart from this, to answer your questions:
To get VS to use GCC as a compiler, you'd pretty much need to turn to makefiles or custom build steps all the way. You'd be much better off compiling from the commandline and using CMake or something similar.
You cannot use the VS debugger for GCC code. GCC outputs GDB compatible debug information, and the VS debug format is proprietary, so nothing will change in that area anytime soon.
Code quality is just as good as you'd want it. See above.
No, the quality of your code will actually increase, as GCC will point out several assumed standard extensions MSVC would hide from you. All self-respecting open source projects can be compiled with GCC.
I my humble opinion, it's depends how someone started to code in the first place. I've been using g++ and gcc for more than 20 years now but the reason why i keep using gcc is mainly for licensing reasons. Although i like it too when i don't have a bunch of runtime dependencies or dll's to bundle with my stuff since i came from the DOS era, i still like my stuff small and fast. gcc for windows comes with standard win32 libraries and common control but i had to develop my own win32 controls for stuff that might require mcf shit to work properly or just to look nicer.
Although gcc might have strong support over internet, when it comes to win32 stuff, many rely on mcf and vc proprietary stuff so again, one may have to work his own issues around and be creative when difficulty arises.
I think it's all about needs and circumstances. If you are just a hobbyist coders and have the time for researches, creating you own libs and stuff but you want a solid compiler that's around since the late 80's and free, gcc sound perfect for the job.
But in the industry visual studio is a must if you want to be competitive and stay in the race. Many hardware manufacturers would prefer bundling visual studio compatible libraries for they hardware over some opensource gnu stuff.
That's my two cents.
To be honest, C++ should be handled with MS Visual Studio. If you want to make cross-platform or Unix apps, use GCC. GCC works and can be used with any IDE other than Visual Studio. Even Visual Studio Code can use GCC. Code::Blocks, Eclipse IDE for C/C++ developers, CLion, Notepad++ and even the good ol' tool we've always known, Notepad works with GCC. And finally, on a PC with low disk space, installing Visual Studio's "Desktop Development with C++" is something like 5 GB, if it was to be useful. And this is where GCC hits MSVC hard. It has native C support. MSVC can compile C, but only with a lot of fine-tuning. It takes a lot of time and effort to finally be able to compile. The final verdict:
If MSVC works, it hella works! If MSVC doesn't work, it HELLA DON'T WORK.
If GCC installs, it works, and if it doesn't work, it's the IDE's problem.
GCC is for people who don't mind spending 4 hours at the computer making it work properly. MSVC is for those who don't care about C and want it to install without any pokin' around.
It can't be used as a direct swap-out replacement for the microsoft compilers, for a start it has a vastly different set of command line arguments and compiler specific options.
You can make use of MinGW or Cygwin to write software but introduce extra dependencies ( especially in the case of cygwin ).
One not often touted advantage of gcc over cl is that gcc can be used with ccache to drastically speed up rebuilds or distcc to build using several other machines as compiler slaves.
Consider the Intel compiler (or "Composer" as they seem to have taken to calling it) as another option. I'm not too sure where its C++11 support is at compared with MS (certainly it has lambdas), but it does integrate very nicely with VisualStudio (e.g different projects within a solution can use the Intel or MS compilers) and there's also been some efforts made to match the MS compiler commandline options.
GCC and MSVC use different name mangling conventions for C++. C++ dlls compiled by one compiler can not be used in applications compiled with the other. I believe this is the main reason we don't see more widespread use of gcc in windows.