There will be a number of changes in Visual C++ 2005 that will break past programs. These changes have not been made casually—generally there is a strong reason for the change. As developers using Visual C++, you should be aware of these changes before you upgrade.

Allowing Change in Visual C++

The Visual C++ team has an entire process for considering changes in the product. It is considered very serious when a change is being made to Visual C++ that could break prior code. Even so, there are a number of reasons for breaking code in a new edition:

One of the key features of Visual C++ 2005 is that it is even more conformant with the C++ standards. This allows for more portable code across platforms and into other tools. Things such as lifetime of variables declared inside a for scope (for-scoping) and variable types will now fit the C++ standards. Conformance to the standards will also be the default settings in Visual C++ 2005. To gain this conformance, some things that were allowed in the past may no longer work.

Security has been a very hot topic over the past few years and will continue to be critical going forward. C++ allows you the power to do nearly anything. To help alleviate the number of security issues and to make code less error prone, Visual C++ 2005 has a number of changes. It introduced a secure CRT and deprecated the unsecure APIs. It also introduced the security checks that are on by default now.

Serviceability has also been added to the product. This allows for easier updateability of the binary files in VC++. It will now be easier for vulnerabilities to be patched and fixed.

Maintenance can also be a cause for making breaking changes. For example, low-value features may be removed from the product to eliminate the need to continue to maintain them. As an example, single-threaded CRT was removed from Visual Studio 2005 because it really wasn't needed. There are better alternatives and the time previously spent maintaining this can now be focused on more important issues.

Finally, a breaking change may be added in order to increase the reliability of the VC++ compiler. Microsoft wants to insure there is a well-defined and consistent behavior within Visual C++.

Some changes are avoided. Most changes to Visual C++ are at the source code level. If these changes impact backward binary compatibility, the change may not happen. Source compatibility will be broken before binary compatibility will be. A change will also be avoided if it could seriously cause people to avoid adopting or upgrading to 2005. This can be changes because of breaking code or because it adds cost. Finally, a coding change must have enough value to justify the cost of making the change. If the cost isn't justified, there is obviously no point in implementing it.

Ten Breaking Changes in the Visual C++ Library

There are a number of changes in the Visual C++ 2005 Libraries that could break your existing application code. Before upgrading to Visual C++ 2005, you should verify that you don't have any of these issues in your application code.

Parameter Validation

In the C Runtime Libraries, code has been added to validate parameters. For example, if you pass a destination buffer whose size is smaller than necessary to strcpy, you can cause a security risk. Parameter validation code will invoke an invalid parameter routine. In release, this will call Dr. Watson. In debug, it will assert. As long as you are passing valid parameters, this will not be an issue.

If you are passing invalid parameters, this will break your code.

Warnings for Insecure APIs

A set of functions within the CRT has been deprecated. New secure versions have been provided. Most of the deprecated functions can cause a buffer overrun or other security issue, if improperly used. These are functions such as strcpy, strcat, and so forth. The new, secure versions have been given a suffix of _s to make them easily identifiable. For example, functions include strycpys ,wcscpy_s, mbscpy_s, calloc_s, and strcat_s.

If you want to continue to use the old, insecure versions of these functions, you can use a #define value of _CRT_SECURE_NO_DEPRECATE. It is recommended, however, that you update your code to use the secure versions.

Iterators Out of Range

SCL checked iterators and debug iterators have been updated for security reasons. If you go out of range with a checked iterator, an "invalid parameter" routine will be called.

Again, you can avoid the invalid parameter and have an out-of-range exception thrown instead. This can be done by using the #define value of _SECURE_SCL_THROWS. By setting this define value to 1, an exception will be thrown instead of calling the invalid parameter handler.

You can turn this iterator checking off by setting the #defined value of _SECURE_SCL to zero. By default, this is turned on.

Type time_t

The type, time_t, is used to represent time in seconds from 1970. Up until 7.1, this was defined as a long. It is now of type 64-bit, so you can do times to the year 3000.

Linking to CRT

Managed applications cannot statically link to CRTs. Whereas you could build a CLR application in 7.0 and 7.1 by linking statically to the CRT, you cannot do that in 2005.

Single-Threaded CRT Support

Single-threaded CRT support has been removed. You had an option to link to the multi-threaded or single-threaded CRT. Going forward, it is believed that most people will want to work with the thread-safe multi-threaded routines.

_nolock suffix routines can be used to optimize your code. In exchange for being optimized, these functions are not thread safe.

Exception Handling

There are two types of exception handling that you could use: /EHa (asynchronous) and /EHs (synchronous). If you used the /EHs switch, on a catch(...) block you may or may not have caught structured exceptions; the behavior was undefined and thus unreliable. You are now guaranteed that structured exceptions will not be caught when /EHs is used. If you want to catch asynchronous exceptions, you should compile using the /EHa switch.

Order of Initialization

Behavior was not defined if you had both managed and native globals. If you had a managed and a native object that interacted, there was no guarantee as to which would be initialized first. Now, you are guaranteed that all native globals will be initialized first, followed by managed globals.

Printf

The %n format specifier in the printf set of functions will allow for printing the number of characters printed so far. This was a security risk and has thus been disabled. It can be enabled by using set_printf_count_output. Passing set_printf_count_output a 0 (zero) disables it. Passing any other value enables it.

The swprintf function

The swprintf function signature did not conform to the C++ standard, so it was changed to fit the standard. In C++, an overload was added with the appropriate arguments. The prior version of the method has been deprecated. In C, overloading is not allowed, so an error will be returned if you use the old format.

In previous versions, a pointer to a member could be obtained without using the address-of operator. Now, this functionality is conformant with standards. This should help to eliminate potential runtime errors. This fix caused a lot of changes in the MFC libraries, so it is possible it could cause issues in your programs as well.

Scoping Rules

Within for statements, scoping rules are not enforced by default. In prior versions, the lifetime duration of a for loop variable would live beyond the for statement. To be conformant with standards, this is no longer the case.

Type wchar_t

The wchar_t type is now built-in by default. There was a chance that you could have had wchar_t variables show as unsigned short because it wasn't built in. This could cause issues when trying to match up signatures with other files that did have wchar_t typed variables. In 2005, wchar_t is a built-in type. You will need, however, to make sure that your previous usage of this did not cause a translation to unsigned short.

Exception Handling

The compiler was changed to avoid catching structured exceptions to work with the library changes that were made. You should really be using /EHa anyway.

Attribute Parameters

To provide for more robust attributes, the compiler will now check against types, enumerations, and such. This means that you can get a compiler error on your attributes that you may not have gotten before.

Int by Default

Defaulting to an int is no longer accepted to conform to the C++ standard. It will still apply in C, but not C++. This change broke a lot of existing code for Microsoft, including NT code, so you will want to confirm your code doesn't break. It is always best to be explicit.

Managed Code with C

The C compiler should not be able to create managed code for the CLR. The C language is not object-oriented and thus doesn't fit with the model used for the CLR. Thus, any files compiled as C files will conflict with the CLR compiler flags. For example, if you use the /TC flag when compiling, you will have a conflict if any CLR flags are also used.

New Syntax to Target the CLR

By using the /clr option, the C++ compiler only accepts new syntax. This will help to enforce the new syntax added in Visual C++ 2005, as well as help to deprecate old code.

Security Checks

With security being the flavor of the day, it makes sense that the default for the security check switch (/GS) should be on. With 2005, /GS is now on by default.

In Conclusion

This article presents some of the key breaking changes as identified by Microsoft. This is not all of the changes, nor is this necessarily the ones that will impact you the most. The items presented here are the ones that were identified to be the most likely ones to cause you problems.

Ultimately, before upgrading or starting changes to your programs using the new version of the compiler, you should first try compiling your existing programs to verify that they don't break. If they do, the chances are you had an issue that should be fixed.


引自：http://www.codeguru.com/cpp/cpp/cpp_mfc/portability/article.php/c9523__3/