C++ and the use of old Visual Studio versions

Question

Based on the behavior of some of our customers, I have come to wonder if many c++ development shops decided to just stop at vs2005. Is this just a quirk of the dozen or so large organizations that we deliver DLL+IMPLIB to, or is there a general groundswell of disinterest in the industry at large in upgrading?

Note that there's no MFC at work here, just a Windows compile of C++ code that is also delivered on linux and whatnot. And the question is, "Is it my imagination, or is it that big companies that build things like search engines in C++ have just stopped upgrading?"

NOTE

None of the answers so far appear to report actual personal experience with making a decision to upgrade or not, but rather either offer general principles or report very vague hearsay.

Answer 1

Any upgrade including buying a new version of VS costs money. In many cases there is no real benefit in getting "the latest thing" that justifies the cost. Waiting has its benefits:

• Any intial bugs are fixed and you potentially save time that may have been wasted with a bad comiler
• Time taken to upgrade and familiarize yourself with the new evnironment.
• The product becomes cheaper after some time too and dirt cheap after the next "next" version arrives.

Besides, do you really need the latest? VS 2010 is only useful if you are doing Azure applications. If you dont use Dot net you might be better of with VS6!

Companies will always try to sell you a new compiler claiming that it does things faster and better etc. Reality: Visual Studio 2010 takes 10 minutes to load on the average 4 year old systems used in my company; that too after closing all other applications. We will not just be paying for the new Visual Studio but also have to upgrade our PCs and OS. These add up to the cost. We are better off with VS2008 running on Windows XP

Answer 2

The question is, if you have a few hundred thousand lines of fairly badly written MFC (a language / framework that had its hay-day about 10 years ago) based C++ in VS 2005 and you are considering an upgrade to VS 2010:

1. Do you want to spend a week or two or more getting your old junkware to compile in the new compiler that has certain subtle, but very annoying differences?
2. Do you want to do a full regression test of that newly compiled code to see if any odd memory stuff has happened?
3. Is all of that hassle worth it for (an admittedly very snazzy) new blue background?

Answer 3

I know a lot of C++ shops that still use VS6.

The problem is often related to old hardware SDK providing support only for the VS6 compiler.

The other problem often cited is that there is more risk to harvest expensive costs in changing the compiler (espcecially with VS) than to continue using the one originally used for production. I think that's a valid reason. Never forget that upgrading have a cost.

In some cases, when the project have to evolve for years or when it's a (very) new project, then it's better to start or continue with the best tools available. In wich case, choosing a more recent compiler is a good idea. Work to fix the breaks from switching to a new compiler is always compensated by better features. If it's not, then the new compiler is just not good enough, so it's not worth.

In the specific case of VS2010, don't forget the interface change. The problem with it is that to run smoothly, the interface requires a somewhat performant computer that not all shops have (being their fault or not). More : any big "change" like this one, that is very apparent, will break any community in "was better before" and "now that's good". So, when they decide to radically change an apparent feature like this one, they know that it will take time before the community get used to it. I guess they will not change the interface system before something like 5 years from now.

Answer 4

There is also a catch-22

If vs2008 works for your product and there is a big cost in fixing it to work with VS2010 then you only do that once you are losing enough customers because of not having VS2010 support to make that worthwhile.

Meanwhile your customers haven't upgraded to vs2010 because they rely on your library (and a bunch of others) that either don't work with vs2010, or might not. They aren't going to go to the time and expense of upgrading until all the libraries they rely on have been upgraded and tested and there are enough benefits to justify the cost

Answer 5

In my opinion, working only with C++, there's just not much reason to upgrade between 2005 and 2010.

Standard C++ support in 2005 is usually "good enough," and support for C++0x won't be fully implemented until the version after 2010, if then.

I've seen few people use any features of VC++ besides the "Build" button, the text editor, and the debugger, and those didn't change much between 2005 and 2008. For 2010 they changed the UI a bunch, but it seems mostly cosmetic, no functionality improvements that I can tell.

Also, most of the Visual Studio upgrades seem focused on working with .NET, so if you're not using that, there's not much reason to spend the money.

Answer 6

You say Visual Studio, but I think you're really talking about compiler versions, so I'm answering in terms of compilers.

I used to work at a company that provided both installable software, and a large set of APIs for customers to build their own plugins and software against ours.

When I first joined, the company officially supported these C++ compiler lines:

• GCC 3.4.6 (Red Hat Enterprise 4)
• GCC 4.1.2 (Fedora Core 7 and Red Hat Enterprise 5)
• Visual C++ 2003/7.1
• Visual C++ 2005/8.0

I joined in August 2008, so Visual C++ 2008 had been out for roughly 8-9 months. There was really no active interest in adding/moving to new versions.

We phased out VC++ 2003 support because Microsoft long didn't support it, and customers had already transitioned to VC++ 2005

As for how we added new C++ compiler support:

The main drivers weren't things like regression testing, or 'what if our code doesn't compile' - a significant portion of the code was written pre-standard C++98, and modern code like I wrote had to compile against the lowest common denominator supported compiler.

The main driver was our customers and their demands.

Beginning in early 2009, some of our customers (I'm talking large defense contractors and such) expressed interest in moving to Visual C++ 2008, and wondering when we'd support that, because they had to build their plugins/extension/software against a compatible version of the libraries. I think they just got a decision passed down from on high, and saw that Microsoft was phasing out support for Visual Studio 2005, so they needed to move up and up.

That sparked the beginning of us building our software against Visual C++ 2008, and that's when these concerns came up:

• regression testing - make sure that people who used VC++2008 coded so that it worked against older compilers
• porting every single dependency to VC++2008 - our software varied from foundational toolkits to network analyzers to full-blown visualization simulation software, so there have to be good financial reasons to spend the money and time to port several dozen dependent libraries and in-house applications to a new compiler
• QAing (we had two QA people and most devs did their own, this is an expensive process)
• Build our software against VC++2008 - not quite so painless

Similar things happened when customers wanted to take advantage of high memory systems and asked us when we'd support 64-bit systems - cue the onslaught of similar tasks as above for building 64-bit VC++2008 software, and 64-bit Red Hat 5 software.

I was involved with a lot of those ports and modifying code to work - Visual C++ 2005 64-bit support, SunStudio 11 support (gave me HUGE nightmares), SunStudio 12 support (also gave me huge nightmares).

Which brings up another point - moving up compilers is not an easy task if your customers demand some oft-ignored compilers - I spent a lot of time rewriting parts of Boost, Qt, and a bunch of other open-source libraries specifically to get software working on some compilers. That followed changes I had to make in a bunch of my company's source code, and you're talking about understanding 5 different code bases and the subtle differences between compilers. Compiler bugs bit me a few times, and I'm sure I could have made a name for myself in the Solaris community with all the modifications I made to make some large open-source projects work on Sun's or IBM's compilers.

When I left the company (late last year), customers were beginning to demand Visual Studio 2010 support because it meant Visual Studio 2008 would soon be phased out. I think the company is beginning to phase out VS2005 support, and GCC 3.4.6 support, because support from Microsoft/Red Hat for those versions of their software/OSes will end.

So no, the code we wrote didn't take advantage of any awesome C++ features, we weren't using std::shared_ptr or std::unordered_map or any C++11 features. We'd use boost to give us that support, but had to guarantee our code could compile against our officially supported compilers. Most importantly, we had to support what a large portion of our customers desired.

Answer 7

Our upgrade from VS6 to VS2008 required one developer working for several weeks to upgrade our codebase before the rest of us could even start the process of upgrading both the software and the coding practices. Then there was testing, and after over a year, we still occasionally hit an obscure bug caused by it.

Our project and make files cannot be upgraded to 2010 (they barely made it to 2008), so that is only used for work on our newest products. Our upgrade will be complete only once all our customers finish migrating, and we don't even have those products ready for beta releases yet. By then, 2010 will be the old obsolete system.