CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There are a number of changes that you can expect to see in Microsoft Visual C++ 2005. In this article, I present a number of changes that can already be found in Visual C++ 2005 that you may encounter when upgrading your own programs. This information is based on a presentation and feedback by Brandon Bray (Visual C++ Program Manager), Alvin Chardon, and Sri Vasudevan.
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.
