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