My department writes a mixture of Windows, Linux and cross platform (RHEL Linx and Windows Server 2003) C++ code for in house applications. We use the STL and Boost 1.39.
VS2010 is now available in my organisation. If we were to move to VS2010 I'd have to make a significant business case for it. What would some of the most noticable benefits we would see from the move? Do you think it would be worth the time cost to move?
Update
Given the size of our code base and the cross platform nature of our code, I'm mainly interested in what the new IDE offers, e.g. how good is the intellisense (say, compared to VS for .net). Does the intellisense work well for very large code bases? What's the refactoring support like? How is raw IDE performance? What is the debugger like, i.e. if I hover over a pointer to a collection of smart pointers is it relatively easy to see what's in the collection?
Thanks in advance
New C++ 0x features, e.g. lambda expressions are really nice to have.
The only real difference in the two compilers is some C++0x support in VS2010. The IDE has improved a lot more, but VS2005 is fine for me too. Now are these worth the time cost to move? Up to you...
Greatly improved IntelliSense. C++0x, which means shared_ptr, unordered_set/map, function, lambdas, etc. This will in practice simplify things for you since you don't need as much from Boost. You also get access to Parallel Patterns Library (parallel for_each, etc) which really helps if you are targeting multi-core. I'd say go for it!
If you're only interested in IDE improvements, and you make a big use of smart pointers, I'd suggest to wait up to SP1 (or some SP that comes with fixes to intellisense).
As some people pointed out, there are BIG changes in C++ intellisense, to support a lot of features that other languages already had for years. The thing is that they accidentally broke the intellisense of smart pointers when instantiated with a template type.
I've posted a question with that issue a couple of weeks ago, and as suggested by someone I sent the issue to Microsoft Connect. Sadly the response from the VC++ team was that it won't be fixed soon.
Since you use STL and Boost, performance might be a pretty big deal. VC2010 supports rvalue references and move semantics, which, even if you don't use it in your own code, speeds up Boost and STL code significantly. (Although I doubt Boost 1.39 utilizes this a lot though. But if at some point you upgrade to a recent version of Boost, you'll get the benefit)
Intellisense was reworked in a big way for 2010. It's still a bit wonky, and falls over the moment it sees a template, as it'll always do for C++, but I have to admit it works much better than it used to.
Related
I have been trying to get our team to migrate a large C++ project to VS2012 from VS2008. I want to do it mostly because I want to start using C++11 and the IDE is much nicer. So my reasons are somewhat selfish.
My team lead is pushing back because he doesn't see the business case for the migration, citing that most performance improvement features we'll get with C++11 we already have with BOOST and other libraries. He also says that this will require changing runtimes on all of our platforms which may change certain behavior. Which would mean we would need to retest on all of the servers that we have deployed to.
The first argument I somewhat understand, although I believe C++11 code will be much cleaner than using BOOST (again not a great business case).
The argument about using different runtimes I don't understand. What runtimes do a native C++ application use? This is not VC++. Would his concern be just that the STL won't be exactly the same implementation?
I don't see what the issue there would be. Is there something I am missing? Are there any other good arguments for migrating that I should cite to help my case?
All 3rd party libraries need to be built with the new compiler
Code might currently be unknowingly reliant on undefined behavior, a new compiler might do something totally different for UB than the current one (and cause problems)
Performance won't change much because you wouldn't have been coding in C++11 style (basically, lots of stuff is passed by value where before it would not have been). If your code base has a lot of...
std::vector<Blah> func(std::vector<Asdf> v); // notice all the pass by value
... C++11 could be a great performance improvement. But in C++98/03 you just wouldn't do that.
You need to lower the barrier to entrance for your team lead. Do the migration yourself and smoke test your product. Then show it to him. After that, here are abstract reasons to upgrade:
C++11 style is less code and simpler
VS2012 has the C++11 standard library additions - you can stop hand rolling 50 bug ridden replacements
Programmers want to work using a modern language and modern tools. This will spark a company wide resurgence of learning and best practices which will improve code quality, employee retention, employee continuing education, etc
It's a delicate balance when to do this sort of upgrade. If you do it too often you're spending money without gaining any business advantage. If you do it too infrequently you're dealing with so much legacy tech and legacy code that maintenance can become a nightmare. When a significant language change comes, that you will ultimately move to, it's best to do it sooner than later (and btw, this isn't particularly soon) - otherwise you just keep accumulating what will later be considered legacy code. Moving to a new compiler for new tools often isn't worth it. Moving for an important language upgrade usually is worth it.
Whether any of that is compelling to your team lead is beyond me. Good luck though
VS2012 is so last year, obsolete already, so good Microsoft replaced it after only 1 year of use, criticisms, eye-blinding whiteness, and ALL CAPS!
But considering that you can build a VS2008 project in the newer IDEs means you can upgrade today to VS2013 and work on upgrading the project to the VS2013 tooling over time.
Your TL is correct though, an upgrade requires a complete re-test, but if you have time between adding features then it is possible to fit such a large test in.
I'd say the main aspect of upgrading is just to keep up to date, its not such a big deal today but in another 5 years time your old VS2008 builds might start to hold you back (as I know having recently upgraded a VS2002 project to 2010), its never a good idea to get so far behind as the longer you leave it, the greater the effort in the upgrade that you will eventually have to do. That's the real reason to do it - chances that Microsoft will not support 2008 builds in the next version, and older IDEs won't run on Windows 9, get greater every year. Best to fix this problem while you have time.
I guess I wouldn't expect much in the way of performance improvements, but regarding testing, I'd recommend full retest on any kind of compiler or tool-chain change regardless of if you change your code or not.
EDIT: I'll add that I'd push to move to the more recent compiler on the next release cycle... that removes the testing argument (since you'll need to test anyway).
I was asking my team to port our vc6 application to vc2005, they are ready to allot sometime to do the same.Now they need to know what is the advantage of porting.
I don't thing they really understand what does it mean to adhere to standard compliance.
Help me list out the advantage to do the porting.
Problem I am facing are
1)No debugging support for standard containers
2)Not able to use boost libraries
3)We use lot of query generation but use CString format function that is not type safe
4)Much time is spent on trouble shooting vc6 problems like having >>
vector<vector<int>>
with out space between >>
Advantages:
More standards compliant compiler. This is a good thing because it will make it easier to port to another platform (if you ever want to do that). It also means you can look things up in the standard rather than in microsoft's documentation. In the end you will have to upgrade your compiler at some point in the feature. The sooner you do it, the less work it will be.
Not supported by MS. The new SDK doesn't work. 64-bit doesn't work. And I don't think they're still fixing bugs either.
Nicer IDE. Personally, I really prefer tabs to MDI. I also think that it's much easier to configure Visual Studio (create custom shortcuts, menu bars, etc.). Of course that's subjective. Check out an express edition and see if you agree.
Better plugin support. Some plugins aren't available for VC6.
Disadvantages:
Time it takes to port. This very much depends on what kind of code you have. If your code heavily uses non-standards compliant VC6 features, it might take some time. As Andrew said, if you're maintaining an old legacy project, it might not be worth it.
Worse Performance. If you're developing on really old computers, Visual Studio may be too slow.
Cost I just had a quick look and Visual Studio licenses seem to be a bit more expensive than VC6's.
Why VC2005? If you are going to invest the time (and testing!) to upgrade from VC6, why not target VC2008?
If you're maintaining a legacy project then there may be no advantage in porting. Simply converting projects and fixing up compiler problems could take weeks of time and introduce instability.
If you're actively developing a product then the main advantage is that you'll no longer be using a product that's over eight years old - which is clearly a good thing.
More recent versions of the Windows SDK don't work with VC6 - if you want to use the latest Windows features, you'll need a more recent compiler.
The later compilers are said to be more standards conforming. I'm sorry I can't be more specific. I do know that VC6 generates lots of compiler warnings just for using standard template classes.
If you use any external libraries that are compiled with a later compiler, you'll need to use something compatible.
Prepare for something of a harsh transition - the IDE's are more different than they should be.
To ensure complete compatibility of the application with different versions of the base platform. And to rectify any errors found thereby so as to give enough freedom to end user to use his own version of the base platform.
I'm not saying you shouldn't convert, but to take your specific points:
1)No debugging support for standard
containers
I debug code using standard containers with VC++ 6 all the time. What's your problem here?
2)Not able to use boost libraries
True. You may find you can use some of the simpler stuff.
3)Much time is spent on trouble
shooting vc6 problems like having >>
[can't get SO to stop mangling this, nb]
with out space between >>
Um, that is a syntax error (at least in the version of C++ understood by VC++6) and will be flagged as such. If your team is spending "much time" on this sort of thing, you need another team.
Edit:
3)We use lot of query generation but
use CString format function that is
not type safe
It will be equally type-unsafe under VS2005. I don't see why this is a reason for porting. If you want type safety use the standard C++ I/O mechanisms.
If your team can't see any advantage and you are unable to explain any advantage, why are you asking them to do this?
Sounds like you are porting just for the sake of it.
I have a client who is still using Visual Studio 6 for building production systems. They write multi-threaded systems that use STL and run on mutli-processor machines.
Occasionally when they change the spec of or increase the load on one of their server machines they get 'weird' difficult to reproduce errors...
I know that there are several issues with Visual Studio 6 development and I'd like to convince them to move to Visual Stuio 2005 or 2008 (they have Visual Studio 2005 and use it for some projects).
The purpose of this question is to put together a list of known issues or reasons to upgrade along with links to where these issues are discussed or reported. It would also be useful to have real life 'horror stories' of how these issues have bitten you.
Not supported on 64-bit systems, compatibility issues with Vista, and it was moved out of extended support by Microsoft on April 8, 2008
http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
Unpatched VC6 STL is not thread safe. See here http://www.amanjit-gill.de/articles/vc6_stl.html, the patches aren't included in the service packs and you have to get them from Dinkumware directly (from here http://www.dinkumware.com/vc_fixes.html) and then apply them to each installation...
The biggest problem that we've seen at my workplace is it's inability to handle even marginally complex templated classes or functions. This fact alone has force some of the most devoted VS6 fans in the company to upgrade and start using VS2005. In addition to the template problem, intellisense is much better, debugging is easier and more accurate, and many people find the IDE easier to navigate. The only downside that we have seen thus far is that builds take a bit longer in 2005 than they did in 6 (but that's probably a side effect of the compiler being more robust)
You can also check out these sites for a sampling of known issues in VS6:
http://louisville.edu/~ecrouc01/CECS302/VisualCPP.htm
http://www.acceleratedcpp.com/details/msbugs.html
I'm sure you could find more if you poked around a bit.
VS6 does not compile code according to the current C/C++ standard. For example,
it has incorrect (outdated) scoping rules for loops. At least one MSFT SDK have been updated now with code that expects the correct semantics, so the SDK won't even compile with VS6 any more.
It has trouble being able to compile all but the most trivial template constructs.
It will compile some template constructs that have been declared illegal in recent standards updates (because the constructs don't actually do what normal users expect).
operator new doesn't conform to the C++ spec and doesn't throw exceptions on allocation failure, fixing this is non trivial.
see: http://msdn.microsoft.com/en-us/magazine/cc164087.aspx
One of the biggest reasons for me to upgrade was the standard compliant C++ compiler ( although still not 100% ), so I could leverage more C++ features in my projects and not worry about strange hacks and workarounds that can lead to hard to find bugs.
Not compatible with Vista. Heck, there's a long list of issues VS 2005 has with Vista.
That being said, most of the improvements in VS seem to apply to everything other than C++ native code. What I'm seeing is more standards compliance, which is important but hardly dramatic.
Visual Studio 6 is not compatible with the lasted Windows SDKs, so it cannot utilize (at least easily) the latest OS features.
Though I no longer have concrete details, I'll just throw in that when we upgraded at work, the new compiler found quite a few errors that VC 6 let slip through quietly. Improved product robustness just from the upgrade.
If they use the STL, they may be interested in the recently-released feature pack, which includes an implementation of TR1.
I have upgraded my stuff but it's relatively uncomplicated. A con to upgrade is VS 2005 DLL Hell
The VS 2008 version of the STL compiles with /clr, so if they're interested in transitioning to the managed world, they don't have to lose all their old code.
By defoult newer versions have better compiler and better libraries. But it's not always easy to port existing projects to newer studio, and you can upgrade both compiler and libraries manually.
I was using VS 6.0 with Intel compiler just year ago. We just had a bunch of old code then, which was threating iterators as pointers and vice versa, and it was all real messy and scary, so this holded us from an upgrade.
But I have had to upgrade after all, because the framework I'm currently using simply doesn't run on VS 6.0. Think this is the ultimative reason :-)
Third-part libraries support only a limited number of compilers, too. Your client may not be able to accept bugfixes or feature upgrades as a result.
For instance, even a widely used library as Boost supports only VS 7.1 and later (source)
And you might have some problems with Data Execution Prevention (DEP) as well, because VC6 ships with an old ATL version. As usual, see Raymond Chen for details.
I was a C++ developer (mostly ATL/COM stuff) until, as many of us, I switched to C# in 2001. I didn't do much C++ programming since then.
Do you have any tips on how to revive my C++ skills? What has changed in C++ in the last years? Are there good books, articles or blogs covering the language. The problem is that most material I could find either targets people who are new to the language or those with a lot of experience.
Which C++ libraries are popular these days? I guess I will need to read on the STL because I didn't use it much. What else? Boost? ATL? WTL?
Boost - though it, and other libraries were around back then, its only relatively recently that it's taken off in a big way. Google for TR1 and c++0x standards too. You should defintely read up on STL because (IMHO) its the thing that makes C++ special.
ATL is as good a dead technology (don't get me wrong, I liked it and still use it somewhat, but its not fashionable in the MS world anymore).
Something like QT is probably more new and cool for C++ developers, and has the advantage of getting you into all the new Linux and web development that'll be increasingly popular over the next few years.
However, once you start looking at the things you can do, I think it'll all come back quite quickly.
I personally find that syntax is where i mostly need to catch up when i wander back to a language i havent used in a long time. But the concepts and what the language is about stays the same in memory.
Assuming its the same with you, i would say its a good idea to relook at the texts you remember to have been useful to you while learning C++. I would recommned Thinking in C++ for getting up fast on the syntax.
STL would be really useful yes. Thats one thing i have found commonly appreciated by all mature C++ programmers. It would be useful to know the libraries that Boost provides.
The changes to C++ world, depends on the changes your favourite compiler has decided to implement. Since you mentioned ATl/COM i assume it would be VC++. The changes to MFC would be support for Windows Forms (2005 vc++) and Vista compliant uI's and ribbon support(?) (2008 Vc++)
VC++ now supports managed C++ -i'm sure you know what that is coming from the C# world - 2008 adds supports for managed STL too.
VC++ is trying to be more standards compliant and are making some progress in that area.
They have introduced lots of secure functions that depreciate the old stds like strcpy and the compilers will also give warnings if you use the old fns.
VC++2005 also has something called function attributes, which it uses to describe the parameters so that it can do more checking on the inputs you pass in and statically flag a warning if it sees soething amiss. Usefuli would say though our shop has not progressed to using the 2005 compiler.
MSDN has the list of breaking changes for each releases. Oh & Support for Windows 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0 has been removed from 2005 version of VC++. Additionally the core libraries you required till now (CRT, ATL, MFC etc) now support a new deployment model which makes them shared side sy side assemblies and requires a manifest.
This link should get you going - http://msdn.microsoft.com/en-us/library/y8bt6w34.aspx
2008 adds even more like Tr1 recommendations, more optimizning compiler, parallel compilation(/mp), support for new processor architectures etc. Open Mp support has also been enhanced in one of these versions is what i remember.
Again refer MSDN - thats the suthentic source for all the answers.
Good luck.
Definitely read the latest edition of "Effective C++" by Scott Meyers. I would also recommend "C++ Gotchas: Avoiding Common Problems in Coding and Design" by Stephen C. Dewhurst.
To sharpen your C++ skills I'd suggest going over some of your old C++ code if you still have access to it. Revisiting it will hopefully trigger those parts of your brain that have laid dormant after switching to C# :)
For libraries STL is good, then boost. I don't think there is too much new stuff going on with ATL/WTL from what you would have known back in 2001.
Just start a project. The libraries you use will depend on your project, but you should certainly read up on the STL. If you haven't used C++ for a long time you might need learn more about templates.
Pickup one of the C++ Unit Test frameworks out there (I suggest Google C++ Testing Framework, aka. gtest). Pick a small project that you can start from scratch and try some TDD. The TDD will encourage you to make small steps and to reflect on your code. Also, as you build your suite of unit tests, it gives you a base from which you can experiment with different techniques.
Rewrite some of your C# stuff using C++
For a start, I'd say try writing code that will work on both a Mac and Windows or Linux and Windows. This will force you to write code that is much more portable than the type of C++ code you can get away with on Visual C++ - there a lot of finer points that are very different when you go cross platform.
I'd suggest stay away from libraries for now if you can - perfect your ANSI C++ game first. I'd also suggest reading up on C++0x - the next standard is due soon and it would help you more to work towards that. To that end, brush up on the STL (the concepts behind it, not the implementation so much) and templates.
If you'd like to try BOOST, go ahead, but you can generally get by without using it. The reason I stayed away from it mostly is because of the way templates are used to do what is needed - a lot of which will become much easier once the new standard is introduced.
UPDATE: Once you're comfortable with the STL and start needing to do things that require a lot of code with the STL or are just plain tricky, then head over to BOOST. Buy a book on BOOST and read it and understand it well.
Take some old piece of code and add to it. This won't get you back on top of the latest C++ trends but it will get your feet wet.
At my job I had to add some features to a C++ ActiveX control and I hadn't touched C++ in years and years and have never done it professionally. Figuring out how to do it again was actually pretty damn cool.
I was in a similar situation: switched from C++ to C# in 2005 and then switched back to C++ in 2007. I can't say C++ universe really changed in those 2 years. The most crucial thing was to regain my memory-management instincts, but that can only be done by practicing.
Now that you have both C++ and .NET under your belt you might want to study C++ CLI a bit (new incarnation of late "Managed C++").
As for books, read everything with "Meyers" and "Sutter" on the cover.
I'm using quite much STL in performance critical C++ code under windows. One possible "cheap" way to get some extra performance would be to change to a faster STL library.
According to this post STLport is faster and uses less memory, however it's a few years old.
Has anyone made this change recently and what were your results?
I haven't compared the performance of STLPort to MSCVC but I'd be surprised if there were a significant difference. (In release mode of course - debug builds are likely to be quite different.) Unfortunately the link you provided - and any other comparison I've seen - is too light on details to be useful.
Before even considering changing standard library providers I recommend you heavily profile your code to determine where the bottlenecks are. This is standard advice; always profile before attempting any performance improvements!
Even if profiling does reveal performance issues in standard library containers or algorithms I'd suggest you first analyse how you're using them. Algorithmic improvements and appropriate container selection, especially considering Big-O costs, are far more likely to bring greater returns in performance.
Before making the switch, be sure to test the MS (in fact, Dinkumware) library with checked iterators turned off. For some weird reason, they are turned on by default even in release builds and that makes a big difference when it comes to performance.
We have done the opposite task recently. Our application is a cross-platform C++ server program and it is built on Windows with VS 2008 (x86) and on HP-UX ia64 and Linux with gcc 4.3 . On every platform we used the STLport 5.1.7 as an STL library and Boost 1.38.
In order to compare performance some time ago we also built our application without STLport and after that we measured performance.
After that on Windows the performance became slightly better. So we chose to stop using the STLport with VS 2008 and to use the default VS 2008 STL library.
On HP-UX ia64 there was 20% decrease in performance. Caliper (the HP-UX profiler) showed that string assignments took more time. And inside of string assignment in the default gcc STL library there were calls to pthread_mutex_unock. As far as I know pthread_mutex_lock/pthread_mutex_unlock are used since the default gcc's STL library uses COW-strings. In our application we do lots of string assignments and as a result of the COW strings we get worse performance. So we still use STLPort on HP-UX with gcc.
In a project i worked on that makes quite heavy use of stl, switching to STLport resulted in getting things done in half the time it took with Microsoft's STL implementation. It's no proof, but it's a good sign of performance, i guess. I believe it's partly due to STLport's advanced memory management system.
I do remember getting some warnings when making this change, but nothing that couldn't be worked around fast. As a drawback, I'd add that debugging with STLport is less easy with Visual Studio's debugger than with Microsoft's STL (Update : it seems there is a way to explain to the debugger how to handle STLport containers, thanks Jalf !).
The latest version goes back to October 2008 so there are still people working on it. See here for downloading it.
I've done the exact opposite a year ago and here is why:
StlPort is updated very rarely (as far as I know only one developer is working on it, you can take a look at their commit history)
Problems building it whenever you switch to new Visual Studio release. You wait for the new make file or you create it yourself but sometimes you can't build it because of some configuration option that you're using. Then you wait for them to make it build.
When you submit a bug report you wait forever, so basically no support (maybe if you pay). You usually end up fixing it yourself, if you know how.
STL in Visual Studio has checked iterators and debug iterator support that is much better than the one in StlPort. This is where most of the slowdown comes from especially in debug. Checked iterators are enabled in both debug and release and this is not something everybody knows (you have to disable them yourself).
STL in Visual Studio 2008 SP1 comes with TR1 and you don't have this in StlPort
STL in Visual Studio 2010 uses rvalue references from C++0x and this is where you get a real performance benefit.
If you use the STLPort you will enter a world where every STL-based third party library you use will have to be recompiled with STLPort as well to avoid problems...
STLPort does have a different memory strategy, but if this is your bottleneck then your performance gain path is changing the allocator (switching to Hoard for example), not changing the STL.
I haven't tried it, but as far as I know, there have been no major changes to Microsoft's STL implementation. (There are no huge new optimizations in VS2008 compiler over 2005 either) So if STLPort was faster then, it's probably still the case.
But that's just speculation. :)
Be sure to report back on the results if you try it out.
One benefit of stlport is that it's open source.