Breaking Changes in Visual C++ 2005, Page 2

Compiler Breaking Changes

In addition to changes that will break the libraries, there are also changes that will break the compiler. The following are the top compiler breaking changes. Again, these are not all of the changes, but are rather the key items that the Microsoft QA team as well as internal partners and VC++ customers at Microsoft identified.

Pointers to Members

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.

# # #