Porting from Code::Blocks to Visual Studio 2010 - c++

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)

Related

Can I build wxwidgets with clang++?

There are walkthroughs to build wxwidgets with common compilers on windows, such as MSVC or MinGW, but there are no options for clang. I do have the other two compilers, but I dislike using Visual Studio for projects that are not C# or other .NET languages and I just don't like MinGW, nothing specifically. I use clang to compile, and I'd like to build wxwidgets with it, but I don't know if it would error or not, so would it work? I'm using windows, if not already clear. Thanks in advance.

You can definitely build wxGTK and wxMac under Linux and Mac respectively with clang and I think people did build wxMSW under Windows with it too, but it's a less commonly used compiler there, so your best bet would be to just try doing it. If you run into any problems, please free to open tickets on wxTrac, we do want to support clang under this platform as well.

Writing C++ code for Linux platform in Visual studio

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).

GCC worth using on Windows to replace MSVC?

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.

Using Visual C++ with a different C++ compiler?

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.

Replacement compiler for Qt Creator?

I like Qt Creator as an IDE, but the built-in compiler is slower than dirt.
Can I replace it, and if so, with what?
Developing on Windows but targeting multiple Mac as well.

By default on Windows the compiler is mingw, a port of GCC. Qt also contains support for the Visual Studio compilers, which you can switch to.
The only full-fledged C++ compiler on Macintosh is GCC.
C++, especially with template heavy code, is slow to compile. There is no avoiding this. In my experience, Visual Studio is not appreciably faster on complex code bases over GCC.

The choice of compiler depends on your toolchain (if you use qmake or cmake) plus your platform (e.g. cl is only available on Windows).
I don't think you can choose arbitrary compilers (e.g. Sun CC, Intel) and QtCreator will correctly picks up the compiling error messages. GCC is still the best supported compiler to use with QtCreator.
Perhaps a solution for you will be to pass -j8 as an extra build flag. Check the Projects pane.