青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

C++ Programmer's Cookbook

{C++ 基礎(chǔ)} {C++ 高級(jí)} {C#界面,C++核心算法} {設(shè)計(jì)模式} {C#基礎(chǔ)}

(vs.net2005 對(duì)c++library的二十個(gè)不兼容) -------Breaking Changes in Visual C++ 2005

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.

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.

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.


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

posted on 2005-12-27 17:04 夢(mèng)在天涯 閱讀(1436) 評(píng)論(0)  編輯 收藏 引用 所屬分類: CPlusPlus

公告

EMail:itech001#126.com

導(dǎo)航

統(tǒng)計(jì)

  • 隨筆 - 461
  • 文章 - 4
  • 評(píng)論 - 746
  • 引用 - 0

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

  •  

積分與排名

  • 積分 - 1811983
  • 排名 - 5

最新評(píng)論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
      <noscript id="pjuwb"></noscript>
            <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
              <dd id="pjuwb"></dd>
              <abbr id="pjuwb"></abbr>
              老司机成人网| 国模吧视频一区| 日韩视频一区| 99人久久精品视频最新地址| 欧美日韩国产一区| 亚洲一区一卡| 欧美亚洲免费| 亚洲国产一区二区三区青草影视 | 99热免费精品在线观看| 日韩亚洲国产精品| 国产区精品在线观看| 噜噜爱69成人精品| 欧美精品福利在线| 久久成人精品视频| 久久久久久久久伊人| 99在线精品视频| 亚洲女ⅴideoshd黑人| 亚洲欧洲一区二区三区在线观看| 一本色道久久加勒比88综合| 国产精品夜夜夜| 另类激情亚洲| 欧美午夜免费影院| 久色成人在线| 欧美三级视频在线| 欧美超级免费视 在线| 欧美性大战久久久久| 久久偷窥视频| 国产精品日日摸夜夜添夜夜av| 久久久综合激的五月天| 欧美精品久久久久久久久久| 久久精品中文| 欧美日韩一区二区三区在线观看免 | 国产精品久久久一区二区三区| 久久久久一区二区三区| 欧美区在线观看| 玖玖视频精品| 国产精品日产欧美久久久久| 亚洲成人在线视频播放| 国产精品成人v| 男女精品网站| 国内精品视频在线观看| 在线中文字幕一区| 9l国产精品久久久久麻豆| 久久国产黑丝| 久久高清国产| 国产精品欧美日韩一区二区| 亚洲精品三级| 亚洲精品日韩激情在线电影| 久久精品导航| 欧美在线视频一区二区| 国产精品女人久久久久久| 欧美激情日韩| 在线看国产一区| 欧美一区二区在线免费播放| 午夜影院日韩| 欧美日韩在线大尺度| 亚洲高清视频一区二区| 在线观看亚洲一区| 久久精品99国产精品日本| 欧美一区二区三区在线| 国产精品久久久久9999吃药| 一本大道久久精品懂色aⅴ| 一本久道久久综合中文字幕| 欧美激情91| 91久久久久久| 一本色道久久99精品综合| 欧美精品一区二区三区很污很色的| 欧美sm视频| 在线不卡免费欧美| 久久资源在线| 亚洲高清不卡在线| 99re在线精品| 国产精品大全| 欧美亚洲视频在线观看| 久久只有精品| 亚洲欧洲免费视频| 欧美日本中文字幕| 亚洲午夜激情在线| 欧美一区中文字幕| 尤物精品在线| 欧美精品www在线观看| 欧美日韩色综合| 久久久免费av| 亚洲国产成人av| 欧美成人午夜| 一区二区三区久久精品| 欧美一级大片在线免费观看| 国产中文一区二区三区| 久久尤物视频| 一二三区精品| 久久久久久夜| 99成人免费视频| 国产精品系列在线| 久久尤物电影视频在线观看| 亚洲免费av电影| 久久99在线观看| 亚洲国产日韩欧美| 欧美性猛交一区二区三区精品| 欧美一区二区三区播放老司机| 亚洲成人在线视频播放| 中文av字幕一区| 国产综合网站| 欧美天堂亚洲电影院在线播放| 午夜在线观看免费一区| 亚洲高清在线视频| 久久国内精品视频| 日韩网站在线| 国内久久婷婷综合| 国产精品v一区二区三区| 久久亚洲午夜电影| 亚洲欧美日韩精品久久奇米色影视 | 国产欧美一区二区色老头| 欧美承认网站| 欧美自拍丝袜亚洲| 一区二区高清在线观看| 欧美freesex交免费视频| 午夜亚洲福利在线老司机| 亚洲国产第一| 黑人中文字幕一区二区三区| 欧美视频在线播放| 欧美成人69av| 久久久久久亚洲精品中文字幕| 亚洲自拍啪啪| 一区二区黄色| 日韩小视频在线观看| 亚洲国产精品va在看黑人| 久久综合九九| 久久久五月天| 久久国产精品99国产精| 亚洲你懂的在线视频| 一区二区三区欧美在线观看| 亚洲日韩欧美一区二区在线| 在线精品亚洲| 在线免费观看一区二区三区| 国产一区三区三区| 国产在线视频欧美| 国产午夜精品一区二区三区欧美 | 免费视频一区| 老**午夜毛片一区二区三区| 欧美诱惑福利视频| 午夜在线播放视频欧美| 亚洲一区二区三区在线播放| 亚洲视频精品| 亚洲影院在线| 午夜精品亚洲一区二区三区嫩草| 在线亚洲免费视频| 亚洲一区二区三区四区在线观看| 在线视频欧美一区| 亚洲综合色在线| 亚洲一区影音先锋| 午夜精品一区二区三区在线播放| 亚洲摸下面视频| 香蕉久久国产| 久久伊人一区二区| 性欧美办公室18xxxxhd| 国产精品国产三级国产aⅴ浪潮| 久久综合九色综合欧美狠狠| 亚洲精品欧洲精品| 蜜臀av一级做a爰片久久| 亚洲性夜色噜噜噜7777| 国产亚洲精品aa| 欧美精品激情blacked18| 欧美黑人在线观看| 亚洲四色影视在线观看| 国产自产在线视频一区| 免播放器亚洲| 久久精品国产第一区二区三区最新章节 | 午夜精品短视频| 一本久道久久综合婷婷鲸鱼| 欧美亚洲在线观看| 免费观看在线综合色| 欧美激情2020午夜免费观看| 欧美国产精品久久| 欧美在线一级视频| 欧美黑人在线播放| 亚洲靠逼com| 一级成人国产| 欧美一区二区三区另类| 亚洲男女自偷自拍| 欧美黄色日本| 亚洲综合国产激情另类一区| 欧美国产91| 美女诱惑黄网站一区| 欧美激情视频在线免费观看 欧美视频免费一 | 国产亚洲成av人在线观看导航 | 夜夜嗨av一区二区三区四季av| 亚洲午夜日本在线观看| 欧美激情一区二区三区四区| 亚洲欧美日韩在线高清直播| 亚洲理伦电影| 日韩一二三区视频| 国产一区二区三区免费在线观看| 欧美日韩激情小视频| 欧美偷拍另类| 国产精品一区二区在线观看网站| 亚洲欧美另类在线| 午夜精品一区二区三区电影天堂 | 久久综合给合| 亚洲人成77777在线观看网| 国产精品久久久久久久久免费樱桃|