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.
Related
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.
When I upgraded from VS6 to VS2005, I saw a 10% boost in the speed of my chess engine program with the default compile settings.
Wondering if the same is true in general, and what improvements, if any, have been made to the final output of the MS C++ compiler since then.
Regarding moving to VC++ 2010+ from versions of VC++ prior to 2010:
If you make heavy use of the STL containers and algorithms, upgrading to VC++ 2010+ may provide substantially more than just a 10% improvement, as VC++ 2010+ implement C++11's move semantics.
I recall a specific post on the Boost mailing list that claimed their application's performance increased by 900% when moving from VC++ 2008 to VC++ 2010 as a result of this:
[boost] [GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
I'm pretty sure every version has added at least a little bit in the way of new/better optimization. For most code I've tested, the improvement is around 3-4% between consecutive versions, so you might see another 10% improvement, but I'd sort of expect a little less.
The limited auto-vectorization introduced in VS2012 (simd intrinsics required in VS2010) might help account for the Boost quotation. VS2013 showed more losses than gains vs. VS2012 in my tests. VS2013 and 2015 seem more oriented to introduction of new syntax rather than performance.
Do you know of any resources highlighting known or possible issues during conversion of a VC++6/Win32 project to VS2010 C++/Win32 project type? I'm interested in all kinds of issues:
Compiler options compatibility
Compile-time issues
Link-time issues
Runtime issues
MFC issues
Otherwise, if you already performed that kind of migration, what issues have you encountered?
Thank you
VC++6 has non-standard exception handling. We hit a few problems because our code contain this:
try {
//Some code
}
catch (...) {
//Handle error
}
Some developers had relied on this broken behaviour and our application crash badly after being compiled in VS2008.
This article explains it well and how to solve the issue.
First of all, these issues are highly dependent on code quality and how the ancient code has been adapted to fit the VC++6 compiler's "features".
It's not possible to convert .dsp to the VS 2010 format directly (at least with the express editions), you'll have to pass through 2008 to be able to convert.
The conversion wizards should warn and inform you of any issues there might be. I haven't been through this process, but I would think compiler switches are the least of your worries. In general, I would expect bad code to produce a lot more errors you need to worry about instead.
As to your specific queries:
See 3.
VS2010 will take longer.
VS2010 linker will take longer, especially if you enable link-time optimization (introduced in VS 2005)
only if you made non-standard assumptions or if VC++6 has non-standard functions. As long as you recompile the complete project with VS2010 (and thus link it to the latest VC(++) runtime), no runtime issues should occur.
sidenote: I'm not saying the old code is bad, just that a lot of questions on SO regarding VC++6 are caused by bad code quality/conformance.
Heh, vs6 allowed you to use loop variables outside the scope of the loop. ie:
for ( int i=0; i<10; i++ )
{
if( i == 5 )
break;
}
int iVal = i;
This will fail in anything > vs6 :) fails in 2005 and 2010 - although there is a compiler setting that will allow you to force this behavior again (I would suggest just fixing it, don't force it, its noncompliant anyhow), at least in vs2005. I haven't made the dive to 2010 yet, as I do a lot of embedded development, and it seems switching compilers for the embedded stuff is usually a major pain. So, I can't say too much for 2010, but I know that carries through!
Did the move, two painful issues I'm aware of:
- The exception handling default was changed between VC6 and later versions. I believe /Eh was the default and that has changed.
- VC6 runtime (msvcrt DLL) is included in any Windows OS since Win2k, while for any other version you need to install it with your software for almost any OS.
You will have a lot of problems because VC6 was notoriously non-conformant, and your code (especially if you used templates) will likely be full of hacks to make it work that no longer are necessary, as MS did a lot of conformance work for more recent compiler versions, and the VC10 compiler will probably barf on them.
If you have a commercial edition of Visual C++:
Find devenv within your Visual C++ install directory (should be %VS90COMNTOOLS%\..\IDE\devenv.exe
> devenv /upgrade project.sln
> msbuild.exe project.sln /t:Build /p:Configuration=Release /p:Platform=Win32
Check the compilation
but If you have a free edition of Visual C++:
Find vcbuild.exe within your Visual C++ install directory (should be %PROGRAMFILES%\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild.exe)
> vcbuild.exe /upgrade project.sln
/msbuild:Configuration=Release
/msbuild:Platform=Win32
For future builds which don’t need conversion, type:
> msbuild.exe project.sln /t:Build /p:Configuration=Release /p:Platform=Win32
When moving from VS2005 to VS2010, we ran into a problem with a 3rd party library causing one of our programs to crash every time it was loaded. The problem turned out to be caused by Microsoft reversing the default setting for the /NXCOMPAT switch in the linker. That switch controls whether or not Data Execution Prevention (DEP) is enabled or not. Prior to VS2010, the default setting for that switch was NO and the DLL we were using apparently relied upon that setting to function correctly.
I'm not sure how far back the NXCOMPAT linker switch goes. It wasn't listed in any of the settings available in the VS2005 dialogs but it was listed when link /help was run from the command line. I've never been able to find a list of changes such as this from Microsoft, so this kind of bug is VERY tricky to track down.
If you're migrating from VC++ 6 to VS2015 with CLR, existing min and max functions are no longer found, add
#define NOMINMAX
#include <algorithm>
namespace Gdiplus
{
using std::min;
using std::max;
};
Secondly, NAN float changed to nan
Is there anything I should know before converting a large C++ program from VS2005 to VS2008?
I'm working on this very problem right now.
Running WinMerge to see what I've changed...
OK, here is what I had to fix in an huge Win32/MFC client application:
Some MFC functions have become virtual (which were not in the past - CWnd::GetMenu for one, if I recall correctly). Also something related to our legacy mouse wheel support (before Windows had built-in mouse wheel support) somehow broke (I just removed the feature, so I never really figured out why that broke).
Some ATL methods (or method params) have changed to const that were not originally (screwed up my overrides).
The Platform SDK is newer - be careful if you're setting the windows SDK version #defines correctly (we were not in all places - which was dumb). You may now be building with newer versions (Vista/2008) of Win32 structures. This didn't work so great on my XP box.
STDMETHOD now includes __declspec(nothrow) which is 100% right - except this found some problems in our code. Some interface that was written like it would be exposed through COM, but never was, threw exceptions.
The IDE has a bug where disabled breakpoints don't show the hollow circle in the margin if you don't have the break points set to highlight the whole line (which I think is the default for VC++, maybe?).
Most of these issues were due to subtle mistakes in our code or aggressive overloading of MFC/ATL libraries. Since everyone else's code is perfect, you should be fine ;)
At my work we converted a large C++ project from VS2005 to VS2008. There were no issues at all. Needless to say, you should definitely still keep a copy of the old project just in case. :)
Edit: I should have mentioned that the project is meant to be platform-independent, and has no gui components.
If you have to support older platforms, beware: VC2008 is the first version that can't target Win9x or NT4. My company has to stick to VC2005 for that very reason.
If your project is using MFC then you should be aware that it's had a fairly major update in 2008 which could break things. Mostly security and UI updates, so worth doing anyway in my opinion.
See here for more general information on what's changed in VS 2008.
I recently converted a project written using VC++5, which I hadn't touched in 10 years to VS2008. I just loaded the project and let VS2008 convert it. Everything went fine. (project now here: http://www.codeplex.com/Uptime)
In our experience, the projects convert just fine. The only code change we encountered was where _MIN and _MAX were removed - we had to change it to std::min(), etc. Our MFC stuff compiled OK. Our biggest headache was getting VS 2008 versions of third party libraries we bought, and building VS 2008 versions of large open source packages like boost, OpenSceneGraph, and GDAL. Not rocket science - just kind of tedious. I wrote a short synopsis on my blog.
Is there a difference in the syntax that you can't just simply recompile? VS will convert the .sln and vcproj files for you automatically. The rest is just code, and unless you are doing something really strange, it should just recompile as-is.
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