Breakthrough changes in Visual C + + 2005

Microsoft Visual C + + 2005 is a play in the Microsoft Visual Studio 2005 Development Suite, and its innovative integrated development environment and C + + compilers have changed a lot compared to the previous version. In this article, we will explain some of the differences and changes that programmers may encounter when upgrading programs, and these changes are likely to make older programs impossible to compile. In short, these changes are not accidental, behind which there is a strong theoretical basis in support, so the use of Visual C + + programmers, before upgrading, must understand these changes.

Changes that have occurred in Visual C + +

The Microsoft Visual C + + Working Group has been fully considered before making changes to its products, taking into account the impact of these changes on previous code, although this is supported by the following reasons for these changes in the new version:

One of the most important of Visual C + + 2005, is to be more compliant with ISO C + + standards, better porting code across platforms, or integrating into other tools, such as declaring variable lifetimes and variable types in a For loop that now follow the C + + standard, and, in the default setting, following ISO C + + standard. Because of this, in some old code, some of the methods that were possible in the past may now need to be modified to compile.

In the past few years, security is a hot topic, and in the future will be more and more attention. The C + + language gives the programmer the ability to do everything, but there are always two sides to it. To reduce security in your code, and to reduce the likelihood of errors in your code, Visual C + + 2005 makes a series of changes, first by introducing concepts such as security CRT and deprecated non-security APIs, Also, in the default state, Visual C + + 2005 carries out code security checks.

Visual C + + 2005 enhances applicability, which makes it possible to upgrade its own binaries more easily, and it is also easier to fix product vulnerabilities.

Maintainability is also one of the reasons for the changes in Visual C + +, for example, Low-value features have disappeared from the product to reduce the likelihood of maintaining them in the future. One example is that the single-threaded CRT has been removed from Visual Studio 2005 because it is no longer needed, and the time it took to maintain the single-threaded CRT is now available for more important things.

Finally, some of these changes are designed to enhance the reliability of the Visual C + + compiler, and Microsoft has ensured clearly defined and consistent behavior in Visual C + + for this purpose.

Of course, there are some changes to avoid, and most of the changes in Visual C + + are at the code security level, and if these changes affect the compatibility of binary code backwards, it will be avoided because source code compatibility is always discovered before binary code compatibility. Also, if some changes cause people not to use or upgrade to version 2005, this change should be avoided, as this can lead to an increase in the total cost of the software project. Finally, a change in the way code is written can prove worthwhile in terms of cost, otherwise there is no need to implement it.

10 breakthrough changes in the Visual C + + library

Visual C + + 2005 libraries have undergone a series of changes that may have an impact on existing programs, and before you can upgrade to Visual C + + 2005, you must determine that the program does not have these problems.

1, the validity of the parameters

In the C run-time Library, some code has been added to check the validity of the parameters. For example, if the target buffer size that is passed is not sufficient for strcpy-typically this is a security risk, the new version calls an illegal parameter handler at this point. In release, Dr.Watson is invoked, and in the Debug edition, an assertion (assert) is generated, and of course, as long as the parameters passed in the program are valid, there is no problem.

2. Warnings to non-security APIs

In Visual C + + 2005, a set of functions in the CRT are no longer recommended for use, but should use the newly provided secured version. Most of these unused functions, if used improperly, will result in buffer overflows or other security issues, such as strcpy, strcat, and so on. The new security versions of these functions add a _s suffix to the function name to facilitate identification such as strcpy_s, wcscpy_s, mbscpy_s, calloc_s, and strcat_s.

If you want to continue using old version, unsafe functions, you can add #define value of _crt_secure_no_deprecate at the beginning of the source code (where value represents a value); However, it is recommended that you upgrade your code to use a new security function.

3. Iterator out of bounds

The checked iterator (checked iterators) and the debug iterator (Debug iterators) are also updated for security reasons, and an illegal parameter handler is invoked if the iterator is out of bounds.

Again, you can avoid illegal parameter problems by throwing a cross boundary exception. Add #define value of _secure_scl_throws to the code and set the value to 1 so that no illegal parameter handlers are invoked, but an exception is generated.

You can also turn off this iterator check by setting the value of #defined value of _SECURE_SCL to zero, which is typically turned on by default.

4, time_t type

The time_t type is typically used to display the number of seconds since the beginning of 1970. Until Visual C + + 7.1 (that is, Visual C + +. NET 2003), the time_t type is defined as a long, and in Visual C + + 2005, it has been defined as a 64-bit type that can be used to show the time until 3000.

5, linked to the CRT

Managed applications cannot now be statically linked to the CRT. In the past, in Visual C + + 7.0 and 7.1 (referring to Visual Studio. NET 2002 and 2003), you can generate a CLR program that is statically linked to the CRT, but not in Visual Studio 2005.

6. Single-Threaded CRT support

Single-threaded CRT support has been canceled in Visual Studio 2005. And with a development perspective, most people in the future are willing to use thread-safe multithreaded code.
In threads, you can use the _nolock suffix to optimize your code, but at the same time, these functions are not thread-safe.

7. Exception Handling

There are two types of exception handling to choose from:/EHa (asynchronous) and/EHs (synchronous C + + exceptions). In the past, if/EHs was used, then in a catch (...) block, it might or may not be possible to catch a structured exception because this behavior is undefined and unreliable; now, when you use/EHs, you're guaranteed not to catch a structured exception. If you want to be consistent with previous versions of Visual C + + and catch asynchronous structured exceptions, you should still use/EHa at compile time.

8. Initialization order

In the past, if there were both managed and local global variables and objects in the code, the initialization order was indeterminate, and if there were managed objects in the code that interoperate with the local object, it would be impossible to guarantee which object was initialized first. Visual Stuio 2005 now guarantees that all local global variables and objects are initialized before the managed global variables and objects are initialized.

9, printf

For the moment, the%n format indicator in printf is typically used to specify the number of characters for the output. This has been identified as a security risk and has been disabled, but can be enabled by using Set_printf_count_output, by passing to set_printf_count_output a 0 value (0) to disable it, and passing any other value can be enabled again.

10. swprintf function

The swprintf function has also been modified to conform to the C + + standard, and it now follows the C + + standard. In C + +, overloads can be implemented by using the appropriate parameters, and the old version of this function is no longer recommended because it is not allowed in C, so if you use the old format, you will return an error.

Breakthrough changes in the compiler

In addition to the changes that affect the library, there are changes that affect the compiler. The following are major changes in the compiler in Visual C + + 2005, and again, there is no listing of all the changes, but the key changes identified by Microsoft's VC + + users and internal collaborators.

Pointer to member

In previous releases, a pointer to a member could be obtained without using the FETCH operator (&), and now Visual C + + 2005 is strictly standard and must use the FETCH operator, which also helps eliminate potential run-time errors. But it also causes many parts of the MFC library to be modified, meaning that it may have an impact on existing programs.

Scope restriction Rules

In the For Loop declaration, the scope restriction rule is not enforced by default. In previous releases, the lifetime of a variable in the for loop would extend beyond the loop, and the variable defined in the For loop, which is compatible with the standard, is now restricted to use within the For loop.

wchar_t type

wchar_t is now a default built-in type. That is to say, perhaps in the past, wchar_t might have been treated as a unsigned short because it is not a built-in type, so it is likely to cause problems when compared to those that have wchar_t type variables. In Visual C + + 2005, wchar_t is already a built-in type, that is, it is necessary to determine that previous usage of wchar_t does not cause translation to be a unsigned short.

Exception handling

To keep in line with the changes in the library, the compiler has made some modifications so that the structured exception is not caught. Therefore, you should use/EHa to remain compatible with your previous code.

Parameter properties

To provide more robust properties--and for the robustness of the code--the compiler will now examine the properties of types, enumerations, and so on. This means that the previous code might encounter an unprecedented compiler error in the property aspect.

The default is int

To follow the C + + standard, a variable or function that has no type declaration is no longer default to the int type. But still in C, the C + + language is no longer available. This has even affected Microsoft's own code, including the NT system code, so the best way is to explicitly declare it.

About managed code for C

The C language compiler is generally not able to create managed code for the CLR because the C language is not object-oriented and does not conform to the model used by the CLR, so any code compiled in the C language will conflict with the CLR compiler settings. For example, if you use the/TC setting at compile time and the CLR is set, it can cause conflicts.

New syntax for the CLR

The C + + compiler accepts only the new syntax by setting the/clr compilation options. This will force a new syntax to be added to Visual C + + 2005, while also discarding old code.

Security checks

Security is getting more and more attention today, security check Options/GS, by default is open, there is a certain reason. In Visual C + + 2005, the/GS option is used by default.

Conclusion

This article lists some of the key changes in Microsoft's confirmed Visual C + + 2005, although not all changes are the most likely to impact code changes, but the items listed here will most likely lead to problems.

In the end, before upgrading or modifying a program with a new compiler, you must first try compiling the existing program to confirm that the code compiles, otherwise you will inevitably have to fix the problem in the source code.