Related
Visual Studio 2015 has got a lot of changes on the C++ compiler side and I'm looking for a benchmark/performance comparison between the Intel C++ compiler and Visual Studio 2015 !
About performance, I mean the performance of the generated code, something like this : https://software.intel.com/en-us/c-compilers/iss
Is there an interest to use the Intel C++ compiler ? Will it produce faster code ?
Thanks
Few year ago, i did some tests on a mac-pro with intel proc.
Results:
icc+linux
vc+win
icc+win
gcc+linux
icc+linux was the very best.
vc+win, icc+win were pretty close.
Explanation: the more the software editor can exploit assertion on the system+hardware, the more it can design a compiler generating fast running code.
Intel is the best because it can exploit its processor and the system (open source).
VC under windows works great too, they know their OS.
Now, this depends of the kind of software. If your program will load a lot of data from disk the best will certainly be vc+win (they have great implementation of internal buffers...). If your program is very multithreaded, icc+linux is gonna win for sure. These are only 2 examples I can talk about because I tested these use cases.
I compared ICC and VC on Windows, and they were very close in terms of performance. I was able to make ICC beat VC only by using the "profile guided optimization" feature.
I'm wondering how well writing software in C++11 works on Windows yet. It would be most comfortable (and propably most natural) to use one of the native compilers for Windows - I'm thinking about Visual Studio 2012 Express or Visual Studio 2013 Express here. Everything I could find so far on that matter is
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
(Comparison of C++11 features of VC10 and VC11, which seems to be quite bad)
http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx (not really transparent, didn't give me a good idea how well it works)
Does anyone have any experience how well the current Visual Studio versions can handle C++11? I really want to start using auto, lambdas, variadic templates, template aliases, initializer lists and rvalue references (to name just a few) and all the other good stuff right now, but if Windows might be a problem I might have to use C++03 further.
Another possibility seems to be to install LLVM and Clang on Windows. My primary platform is OSX, and on that system Clang's support for C++11 is really good. But I read that the LLVM-version of the standard library for C++ (libc++) does not work well on Windows. So LLVM/clang might not be an option.
What are your opinions on C++11 development on Windows?
Thank you!
I can only give you my experience as a developer, as I've been building against the cutting edge of C++ on Windows using Visual C++ for just about everything, while also installing several other compilers and IDEs (including building Clang myself on Windows for Visual Studio 2012, 2012 CTP, and 2013 Preview). The following is my experience up until right now (August 13th, 2013), and is based on Herb Sutter's talk and working with the compiler every day.
The Quick
Run in the opposite direction of Visual Studio / VC++. Support for C++11 is slow, and they're currently being crushed in terms of compiler features versus Clang and GCC.
The Present
Visual C++'s C++11 (and C++14 support) is beyond abysmal right now. They lack powerful features that make template metaprogramming in C++ great (using expressions in particular).
Using doesn't exist right now. I have spent hours and hours porting great C++11 code with using to VC++, only to have it break it certain places, snap, or just become near damn unmaintainable.
Variadic support in the CTP was horrifically terrible, and while it got better for Visual Studio 2013 Preview's version of the compiler, it's still fairly bad at complex variadic and template expressions that obey the standard (and compile fine in GCC and Clang).
=delete and =default are pretty much gone from VC++ right now; in the hopeful near future, maybe it will work out (and it should come "soon-ish", according to the roadmap) (I had to implement r-value constructors explicitly for many simple classes all the way down a 8-class inheritance hierarchy once. It was the worst slap in the face, when I watched GCC and Clang users get all of my explicit hardcoded work for free with =default).
As a holdover (primarily because of Windows OS code and some binary compatabilities), Empty-Base-Class-Optomizations in VC++ don't work. Don't expect your class hierarchy sizes or member layout to be optimized in the least (watch your ordering in std::tuple when packing variable types).
This is about all the frustrations I've come into contact with so far. They're work-aroundable -- I have to work with them every day -- but if you want great C++ support, you should jump for GCC or Clang and somehow make it work on your machine.
The Future
If you really want C++11, you will need to wait about a year, and even then Visual Studio 2013's release of VC++ will still be missing a few features (and don't expect them to be bugless either). VC++ for 2013 will also still be critically missing std::move and explicit r-value support in many places, making it painful when you expect things to work.
The Caveat
If you're not a powerful Vim user, you're low on options when it comes to IDEs that you can work with (that play nice with GDB/GCC or Clang).
QtCreator is nice, works with MinGW, and is generally fully featured enough to get work done.
Sublime Text can be used, but you'll have to write your own building system or delegate that to something else.
Code::Blocks's autocomplete is wonky and behaves strangely, and the IDE itself feels clunky.
Eclipse is supposed to be good, but my experiences with it are clunky and strange, with odd input lags at time (despite a 8.00 GB i7 Haswell machine using an SSD).
Visual Studio, as an IDE, is pretty solid. Then stack Visual Assist X on top, and it works pretty damn well for C++ coding. It's really the only reason I continue to stick with it, but I've already made headway into learning Vim so I can mostly ditch Visual Studio altogether, when the time comes.
About Libraries
Library support in VC++ is pretty complete (for as much as their broken compiler lets them be complete). It has regex, while most other libraries have non-existent or broken regex support. But that doesn't mean that the VC++ library plays nice with some C++11 features that it says it does (picture by melak47).
And Lastly
If you want code that you know is going to work in Windows, 100%, for the rest of eternity, you'll probably want to program against VC++. The other "benefit" is that the code you write in VC++ is the smallest subset of C++/C++11 you can write with, so in the end it should compile everywhere. Of course, that goes against the very idea of using beautiful C++11 and enjoying it, so... pick your poison(s) wisely.
VC's C++11 support is far from complete, but it does include the most important user-facing features.
And here's the other thing. In my experience, it is fine to install MinGW or Clang on Windows, but you're going to have some inconvenience because hardly anybody precompiles binaries for those compilers for Windows (whereas lots of people precompile binaries for Visual Studio).
In addition, there are as far as I am aware no environments for Windows which are remotely as advanced as Visual Studio for things like graphical debugging, intellisense, and stuff like that. When I tried Code::Blocks it just didn't work, realistically.
You can see here for a comprehensive comparison of compiler support for C++11 language features. Here's some info on VS's C++11/14 roadmap.
MSVC is lagging behind the other major C++ compilers but it's still got support for many of the most important features.
auto, lambdas, and rvalue references are available from VS10. IIRC there's a caveat with rvalue references that the compiler doesn't generate move construction and move assignment operators.
variadic templates and initializer lists are available in the VS2013 preview, including library support.
type aliasing (i.e., typedefs with the using keyword) is expected to be available in VS 2013 RTM.
If you don't need to interoperate with binaries generated by VS then installing another compiler such as GCC is workable. I understand Clang can also work in a mingw environment, with libstdc++ rather than libc++.
http://nuwen.net/mingw.html
The nuwen distro is AWESOME! It is MinGW but it comes out much quicker than MinGW as new GCC releases come out. It also comes with all of boost and other useful libraries already compiled. It is all I use on windows anymore.
We are using C++11 for a few months already in production software across windows and linux in some here.com products without any problems. We use auto, lambdas, range for... Using Visual studio 2012 and gcc 4.7.
I have been using VS2012 and used C++11 features where possible. There are some bugs in the implementations and I have found it helpful to have another compiler to hand when I get errors from Visual Studio to compare against.
Clang and GCC to lead the way in terms of C++11 feature support and it appears to be a neck-and-neck race in terms of C++11 support between the two. MSVC is sadly panting trying to keep up and lagging behind. The Nuwen MingGW distro is, as Jake mentions, excellent and appears to be working well with Eclipse (Kepler release) and I didn't encounter too much pain using it with Netbeans 7.4 either. The Nuwen distro is currently at version 11.2 at the time of writing and, as you can see at Stephan's website, is now x64-native, featuring GCC 4.8.1 and Boost 1.54.0, with GCC's default mode also set to C++11.
I'm certainly beginning to use Eclipse Kepler and Nuwen MinGW in preference to MSVC 2012 more and more, but I'm largely a hobbyist C++ programmer still getting my feet wet and may not have hit the more obscure problems that those to whom C++ is their bread and butter may know about.
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.
We are considering moving the win32 build of our cross-platform C++ application from MS Visual Studio 2003 to MS Visual Studio 2005. (Yes, very forward-looking of us ;)
Should we expect to many code changes to get it compiling and working?
I've just migrated a comparatively large codebase from VS2003 to VS2008 via VS2005 and the majority of issues I found were const/non-const issues like assigning the return value of a function that returns a const char * to char *. Both VS2005 and VS2008 are a lot more picky when it comes to const correctness and if your existing codebase is a bit sloppy, sorry, old school when it comes to const correctness, you'll see plenty of this.
A very welcome change was that the template support in VS2005 is noticeably better than it is in VS2003 (itself a big improvement on earlier versions), which enabled me to throw out several workarounds for template related issues that the team had been dragging around since the heady days of VC++ 4.x.
One issue that you are likely to encounter are tons of warnings about "deprecated" or "insecure" functions, especially if you are using the C string functions. A lot of these are "deprecated by Microsoft" (only that they left out the "by Microsoft" part) and are still perfectly usable, but are known potential sources for buffer overflows. In the projects I converted, I set the preprocessor define _CRT_SECURE_NO_WARNINGS and disabled the warning C4996 to turn off these somewhat annoying messages.
Another issue that we came across is that MS has changed the default size of time_t either in VS2005 or in VS2008 (I apologise but I can't remember - it's definitely in VS2008 but it may already be in VS2005) so if you have to link with legacy libraries that use time_t in the interface, you'll have to use _USE_32BIT_TIME_T to revert to the older compiler's behaviour.
If your solution contains several projects, you may find that the parallel build feature (which is turned on by default) will highlight missing build dependencies. so projects are suddenly built in the wrong order but magically build correctly if you revert from parallel build back to linear build.
Overall I do prefer VS2005/8 to VS2003, and I would recommend to upgrade to VS2008 if that is an option, as the compiler is "better" than VS2005 - MS seems to have made a massive effort in improving the native C++ compiler. Part of that was already noticeable in 2005 so you'll get at least some of the benefit even if you stick to 2005.
If your code is already quite clean and compiles without warning, it's not a big step.
Check this article and consider how big the impact of those changes would be on your existing code. Cleaning up for-loop conformance can be a bit of work.
You can get the free Express edition of Visual Studio 2005 here.
You should review MS's lists of breaking changes when deciding if & how to undertake this project.
Breaking Changes VC 2005 - 2008
Breaking Changes in the Visual C++ 2005 Compiler
Breaking Changes in Visual C++ .NET 2003
you will find alot of string commands will give you warnings as in vis 2005 they stepped up the security to try and stop buffer over runs.
your 2003 code will still compile though.
I recently converted a 10-year old VC6 program to VS2008. It required no changes to the source code, and the only changes needed to the project files were handled by the upgrade wizard.
No. I wouldn't expect more than a few.
Edit: you should/could try the code with a demo version of vs2005 first.
Also, consder disabling checked iterators or the performance may suffer after porting to the new version.
If your source code conforms to the C++ standard, you shouldn't need to change anything to move to 2005. You may get some depreciated warnings, but nothing that should give compile errors.
The main issue people have with going from older versions of VS to newer ones is that the newer versions are more standard conforming.
Things like:
for(i = 0; i < length; ++i)
{
}
when i is undefined prior to that point work fine in previous versions of VS, but in 2005 it correctly marks i as an undefined variable.
What are the advantages/disadvantages between MS VS C++ 6.0 and MSVS C++ 2008?
The main reason for asking such a question is that there are still many decent programmers that prefer using the older version instead of the newest version.
Is there any reason the might prefer the older over the new?
Advantages of Visual Studio 2008 over Visual C++ 6.0:
Much more standards compliant C++ compiler, with better template handling
Support for x64 / mobile / XBOX targets
Improved STL implementation
Support for C++0x TR1 (smart pointers, regular expressions, etc)
Secure C runtime library
Improved code navigation
Improved debugger; possibility to run remote debug sessions
Better compiler optimizations
Many bug fixes
Faster builds on multi-core/multi-CPU systems
Improved IDE user interface, with many nice features
Improved macro support in the IDE; DTE allows access to more IDE methods and variables
Updated MFC library (in VS2008 Service Pack 1)
support for OPENMP (easy multithreading)(only in VS2008 pro.)
Disadvantages of moving to Visual Studio 2008:
The IDE is a lot slower than VS6
Intellisense still has performance issues (replacing it with VisualAssistX can help)
Side-by-side assemblies make app deployment much more problematic
The local (offline) MSDN library is extremely slow
As mentioned here, there's no profiler in the Professional version
In the spirit of Joel's recent blog post, I've combined some of the other answers posted into a single answer (and made this a community-owned post, so I won't gain rep from it). I hope you don't mind. Many thanks to Laur, NeARAZ, 17 of 26, me.yahoo.com, and everyone else who answered. -- ChrisN
Well, for one thing it may be because the executables built with MSVS 6 require only msvcrt.dll (C runtime) which is shipped with Windows now.
The MSVS 2008 executables need msvcrt9 shipped with them (or already installed).
Plus, you have a lot of OSS libraries already compiled for Windows 32 bit with the 6.0 C runtime, while for the 2008 C runtime you have to take the source and compile them yourself.
(most of those libraries are actually compiled with MinGW, which too uses the 6.0 C runtime - maybe that's another reason).
I would like to add that it's not the case that applications developed using Visual C++ 2008 must require more DLLs than those developed using Visual C++ 6.0. That's just the default project configuration.
If you go into your project properties, C/C++, Code Generation, then change your Runtime Library from Multi-threaded DLL and Multi-threaded Debug DLL (Release and Debug configurations) to Multi-threaded and Multi-threaded Debug, your application should then have fewer dependencies.
Off the top of my head, the advantages of the new Visual Studio are:
stricter adherence to standards
support for x64 / mobile / XBOX
targets
better compiler optimizations
(way) better template handling
improved debugger; possibility to
run remote debug sessions
improved IDE
improved macro support; DTE allows access to more IDE methods and variables
Disadvantages:
IDE seems slower
Intellisense still has performance
issues (replacing it with
VisualAssistX can help)
runtime not universally available
source control integration not up to
par (although in all fairness VC6
lacks this feature completely)
Did you know that MS VC6's implementation of the STL isn't thread-safe? In particular, the reference counting optimization in basic_string blows up even when compiled with the multi-threaded libraries.
http://support.microsoft.com/kb/813810
Besides the deployment mentioned above, the main advantage of MSVC 6.0 is speed. Because it is a 10 year old IDE it feels quite fast on a modern computer. The newer versions of Visual Studio offer more advanced features, but they come at a cost (complexity and slower speed).
But the biggest draw-back of MSVC 6.0 is its non-compliant C++-Compiler and Library. If you intend to do serious C++-Programming this is a show-stopper. If you only build MFC-Applications it is probably not much of a problem.
Visual C++ 6.0 integrates with memory tracking tools, such as Purify, HeapAgent, BoundsChecker and MemCheck, thoroughly and well since those memory tracking tools were actively maintained and aggressively sold after Visual C++ 6.0 came out.
However, since C++ has been out of vogue for a while, the companies that sell memory tracking tools still sell them but never update or integrate them with new Visual C++ versions, including Visual Studio 2008. So, using memory tracking tools with Visual Studio 2008 is frustrating, errorprone and, in some cases, impossible.
Since VC6 most of the focus of Visual Studio has been on C# and .NET, as well as other features, so some C++ old-timers see VC6 as the good old days. Things have improved in Visual Studio for C++ developers since those days, but not nearly as dramatically as for .NET users.
One way that VS2008 is significantly better than VC6 is that it can build C++ projects in parallel. This can result in significantly faster builds even on a single CPU system, but especially if you have multiple cores.
If you install all service packs for VS6 you still have a solid IDE/compiler combo. As a software developer who have to release products in the wild (over Internet) I don't want to o ship the VC++ runtimes and .NET framework everytime (I can't bundle them directly in my installer/executable, its forbidden by Microsoft). You know, several megabytes of runtimes to run kilobytes of code is kinda stupid. VC++ 6.0 only need your executable and 2 .DLL at best.
Also, debug runtimes cannot be distributed with VC++ .NET, not really good when I have a client which need to do some debugging of my products :)
There is in my opinion the major reasons why I still use VC++ 6.0, but the IDE itself is ugly (ie: no tabbing support). I usually bypass the IDE limitations by using codeblocks instead (CodeBlocks support CL.EXE/LINK.EXE for all VC++ versions)
Cobolfoo
Visual C++ 2008 is much more standards compliant (Visual Studio 6 doesn't support the C++ standard set in 1998).
VS2008 has better compiler (much more standards compliant, better optimizations, ...).
VS6 has much faster IDE. VS2008 IDE has many nice features, but it is a low slower than VS6.
Quick list of improvements you'll see going from 6.0 to 2008:
Many bug fixes
Better conformance to the C++ standard
Better compiler optimization
Improved UI (better intellisense, etc)
One thing that people sometimes forget is that VS 6.0 is over 10 years old now! At this point, I don't see how anyone would want to stick with it.
one tough thing we encountered was that "value" became a keyword.
Visual C++ 6 can be very buggy at times compared to 2008. Some things in particular:
Poor template support/oddities (for instance sometemplate<othertemplate<t>> not working, but sometemplate< othertemplate<t> > working)
Not standards compliant
Resource editor is rubbish ("blue lines" seem to move around randomly, among other things)
Only supports editing certain kinds of 8-bit bitmaps (I have to use imagemagick to convert bitmaps saved in paint.net to be able to be seen in picture resources)
Terrible support for working with read-only files / quirky sourcesafe integration.
Sometimes developing in VS6 feels like trying to get websites looking good in internet explorer 5.5