There is no Visual Studio 2015 Service Pack 2 or 3. You're probably talking about: Visual Studio 2015 Update 2 and Visual Studio 2015 Update 3.
So I believe your question should be translated:
Were there any changes made to the C++ standard objects by Visual Studio 2015 Update 3?
You can find a list of the changes made to the C++ compiler here: https://www.visualstudio.com/en-us/news/releasenotes/vs2015-update3-vs#visualcpp
Your question specifically focuses on changes to the standard libraries, which are listed here:
- We've restored debug mode performance when destroying ranges of trivial objects that regressed in Update 2, like in vector.
- We've implemented the swappable traits from the C++17 working paper, from the proposal P0185 Adding [nothrow-]swappable traits. As a speculative C++17 feature, the traits (
is_swappable
, is_swappable_with
, is_nothrow_swappable
, and is_nothrow_swappable_with
) are only visible, and the constraints on std::swap
are only active, when compiling with /std:c++latest.
- We've removed ETW eventing calls from vcruntime140.dll and static libraries that previously fired during process startup and dllmain.
- New We've removed symbol name length in common machinery used by STL containers, such as
std::vector
, reducing likelihood of C4503 warnings. For example, the following type no longer generates a warning: concurrency::concurrent_unordered_map<>>>>
.
The last bullet indicates the symbol naming, internal to C++ objects has changed. Meaning that in an object created by one Update, the symbol names will not necessarily be consistent with the symbol names expected by the other update. So the answer to your question is: No, the objects symbol naming changed between versions. They are no longer guaranteed to be compatible.
Furthermore, I've definitely wasted a tremendous amount of time trying to figure out why something that worked in one section of code didn't in another, for me it was just do to a minor update. By my experience I'd implore you: Keep your entire team on the exact same Visual C++ version. If you don't 1 of 2 things will happen:
- You'll have team members that are always suspicious of version differences. If something they expected to work doesn't they'll feel the need to try it on the other version of Visual C++. Even worse they may feel the need to ensure that their code is supported if used in the other version of Visual C++. You will experience a slow and steady time drip here.
- You'll have team members who use functionality that did change between versions. But they don't recognize the version change as the culprit. This problem will cost an exorbitant time volume as identifying the bug will be very difficult.
To summarize the correct answer is to: Get your entire team on a fixed version of Visual Studio, and you won't have that nagging worry in your head or their heads all the time.