• <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>

            C++ Programmer's Cookbook

            {C++ 基礎} {C++ 高級} {C#界面,C++核心算法} {設計模式} {C#基礎}

            移置c++從6.0到2005

            our months ago, Microsoft publicized a list of features that could cause existing Visual C++ apps to break when migrated to Visual Studio 2005. Many of these features are core C++ updates that are meant to bring Visual C++ to full compliance with ISO C++. There's no doubt that these changes are a major improvement over the non-compliant hacks that have been in use since the mid-1990s. The downside is that migrating to Visual Studio 2005 requires a thorough code review—and possibly some repairs. The following sections show some of the code changes required for porting existing C++ apps to Visual Studio 2005.


            Your Visual C++ 6.0 apps will not compile when migrated to Visual Studio 2005 unless you fix them. How do you go about it?


            Use this check list to locate incompliant code spots and repair them according the following guidelines.

            Code Review and Analysis
            Earlier versions of Visual C++ literally forced you to write non-compliant C++ code. Therefore, it's unlikely that an existing Visual 6.0 app will compile as-is with Visual C++ 8.0 (the C++ compiler of Visual Studio 2005). Therefore, your first step is to review the code and locate potential problems. Before you make any changes to the code, my advice is to review the entire code base and systematically mark all code sections that might be incompatible with Visual Studio 2005. Only then should you make the necessary repairs. It's better to repair incompliant code in several passes, each dealing with a different category of fixes. For example, your first pass may focus on for-loops, the next pass on exception handling, and so on. There are three reasons for splitting the code repairs to separate sessions:
            • Team Work: Developers specializing in different categories can work on the same code simultaneously.
            • Coding Standards: It's easier to enforce a uniform coding standard when focusing on one feature at a time.
            • Keyword-based Lookup: Each category is typically associated with a specific C++ keyword (e.g., to locate all for-loops, search for the keyword for).
              Code Review and Analysis
              Earlier versions of Visual C++ literally forced you to write non-compliant C++ code. Therefore, it's unlikely that an existing Visual 6.0 app will compile as-is with Visual C++ 8.0 (the C++ compiler of Visual Studio 2005). Therefore, your first step is to review the code and locate potential problems. Before you make any changes to the code, my advice is to review the entire code base and systematically mark all code sections that might be incompatible with Visual Studio 2005. Only then should you make the necessary repairs. It's better to repair incompliant code in several passes, each dealing with a different category of fixes. For example, your first pass may focus on for-loops, the next pass on exception handling, and so on. There are three reasons for splitting the code repairs to separate sessions:
              • Team Work: Developers specializing in different categories can work on the same code simultaneously.
              • Coding Standards: It's easier to enforce a uniform coding standard when focusing on one feature at a time.
              • Keyword-based Lookup: Each category is typically associated with a specific C++ keyword (e.g., to locate all for-loops, search for the keyword for).

            Code Fixing
            Some of the necessary code fixes are rather straightforward. These include for-loops, pointers to member functions, the deprecated "default to int" rule, and exception handling. Let's see what these all mean.

            • for-loops: In pre-standard C++, variables declared in a for-loop were visible from the loop's enclosing scope. This behavior is still maintained in Visual C++ 6.0:
              
              for (int i=0; i<MAX; i++)
              {
                //..do something
              }
              
              int j=i; //allowed in VC++ 6.0
              
              However, in Visual Studio 2005, the scope of i is restricted to the for-loop. If you want to refer to this variable from the enclosing scope, move its declaration outside the for-loop:
              
              int i=0;
              for (; i<MAX; i++)
              {
                //..do something
              }
              int j=i; //OK
              

              Figure 1. Exception Handling: This image shows how to override the default exception handling command line flag.

            • Declarations of pointers to members: In pre-standard C++, it was possible to take the address of a member function without using the & operator:
              
              struct S
              {
               void func();
              };
              
              void (S::*pmf)() = S::func; //allowed in VC++ 6.0
              
              In Visual Studio 2005, the & is mandatory:
              
              void (S::*pmf)() = &S::func; //OK
              
              Tip: To locate problematic code, search for the tokens ::* and ::.
            • "default to int": Pre-standard C++ (and all C variants predating C99), use the "default to int" rule when declarations of functions and variables do not contain an explicit datatype. This behavior is maintained in Visual C++ 6.0 as the following declarations show:
              
              const x=0; //implicit int
              static num; // implicit int
              myfunc(void *ptr); //implicit return type int
              
              In Visual Studio 2005, you have to specify the datatype explicitly:
              
              const int x=0; 
              static int num; 
              int myfunc(void *ptr);  
              
              Tip: To locate incompliant code of this category, compile your app with Visual Studio 2005 and look for compilation errors about a missing datatype in a declaration.

            • Exception Handling: Older versions of Visual C++ happily mixed standard C++ exceptions with the asynchronous Structured Exception Handling (SEH). Consequently, a catch(...) block might catch not just a C++ exception created by a throw statement, but also an asynchronous SEH e.g., access violation. Not only is this behavior incompliant, it makes debugging more difficult. Visual Studio 2005 fixes this loophole. It's now possible to specify whether a catch(...) handler should catch only C++ exceptions by using the default /EHsc flag (this is the recommended option), or maintain the non-standard behavior of Visual C++ 6.0 by using the /EHa flag (see Figure 1).

            Author's Note: The fixes shown here don't reflect all of the changes in Visual Studio 2005. For a complete list, consult Visual Studio 2005 homepage. Also, I have focused on core C++ features. Other Visual C++-specific changes such as multithreaded CRTs, deprecated APIs etc., aren't discussed here.

            Code Fixing
            Some of the necessary code fixes are rather straightforward. These include for-loops, pointers to member functions, the deprecated "default to int" rule, and exception handling. Let's see what these all mean.
            • for-loops: In pre-standard C++, variables declared in a for-loop were visible from the loop's enclosing scope. This behavior is still maintained in Visual C++ 6.0:
              
              for (int i=0; i<MAX; i++)
              {
                //..do something
              }
              
              int j=i; //allowed in VC++ 6.0
              
              However, in Visual Studio 2005, the scope of i is restricted to the for-loop. If you want to refer to this variable from the enclosing scope, move its declaration outside the for-loop:
              
              int i=0;
              for (; i<MAX; i++)
              {
                //..do something
              }
              int j=i; //OK
              

              Figure 1. Exception Handling: This image shows how to override the default exception handling command line flag.

            • Declarations of pointers to members: In pre-standard C++, it was possible to take the address of a member function without using the & operator:
              
              struct S
              {
               void func();
              };
              
              void (S::*pmf)() = S::func; //allowed in VC++ 6.0
              
              In Visual Studio 2005, the & is mandatory:
              
              void (S::*pmf)() = &S::func; //OK
              
              Tip: To locate problematic code, search for the tokens ::* and ::.
            • "default to int": Pre-standard C++ (and all C variants predating C99), use the "default to int" rule when declarations of functions and variables do not contain an explicit datatype. This behavior is maintained in Visual C++ 6.0 as the following declarations show:
              
              const x=0; //implicit int
              static num; // implicit int
              myfunc(void *ptr); //implicit return type int
              
              In Visual Studio 2005, you have to specify the datatype explicitly:
              
              const int x=0; 
              static int num; 
              int myfunc(void *ptr);  
              
              Tip: To locate incompliant code of this category, compile your app with Visual Studio 2005 and look for compilation errors about a missing datatype in a declaration.

            • Exception Handling: Older versions of Visual C++ happily mixed standard C++ exceptions with the asynchronous Structured Exception Handling (SEH). Consequently, a catch(...) block might catch not just a C++ exception created by a throw statement, but also an asynchronous SEH e.g., access violation. Not only is this behavior incompliant, it makes debugging more difficult. Visual Studio 2005 fixes this loophole. It's now possible to specify whether a catch(...) handler should catch only C++ exceptions by using the default /EHsc flag (this is the recommended option), or maintain the non-standard behavior of Visual C++ 6.0 by using the /EHa flag (see Figure 1).
            Author's Note: The fixes shown here don't reflect all of the changes in Visual Studio 2005. For a complete list, consult Visual Studio 2005 homepage. Also, I have focused on core C++ features. Other Visual C++-specific changes such as multithreaded CRTs, deprecated APIs etc., aren't discussed here.
            Just in the Nick of Time
            Visual Studio 2005 and Visual C++ 6.0 have different Application Binary Interfaces, or ABIs. This means that the same datatype or function may have different binary layouts and mangled names. The different ABIs affect among other things the std::time_t and wchar_t datatypes.

            Visual C++ 6.0 treats std::time_t as a 32-bit integer, whereas in Visual Studio 2005 this type is a 64-bit integer. This change might necessitate code updates if your app assumes a 32-bit time_t e.g., hard-coded buffer sizes and format flags (further information on migrating to 64-bit code is available here). Another ABI change affects the representation of the wchar_t type. Up until now, wchar_t has been a typedef synonymous with unsigned short. However, Visual Studio 2005 treats wchar_t as a built-in type. This change might affect the overload resolution of functions:

            
            int _wtolowers(unsigned short *ws);
            wchar_t ws[10] = L"Test";
            _wtolowers(ws); 
            
            This code compiles with Visual Studio 6.0 but it will break with Visual Studio 2005 because wchar_t * is incompatible with unsigned short *.

            All and Sundry
            The changes described here affect not just Visual C++ 6.0 code ported to Visual Studio 2005. Rather, they apply to legacy C++ code ported to an ISO compliant C++ compiler in general. The fear from these changes has led many project managers to defer upgrades at all costs. This policy isn't justified, though. Almost without exception, these changes are only for the best.

            Danny Kalev is a certified system analyst and software engineer specializing in C++ and the theoretical aspects of formal languages. He is the author of Informit C++ Reference Guide and The ANSI/ISO Professional C++ Programmer's Handbook. He was a member of the C++ standards committee between 1997 and 2000. Danny recently finished his MA in general linguistics summa cum laude. In his spare time he likes to listen to classical music, read Victorian literature, and explore natural languages such as Hittite, Basque, and Irish Gaelic. Additional interests include archeology and geology. He also gives lectures about programming languages and applied linguistics at academic institutes.


            引自:http://www.devx.com/cplus/10MinuteSolution/28908/0/page/1


            -------------------------------------------------------------------------------------------------------------------

            VC6==>VS2005的一些問題

            我接收到一個任務,是把公司的一個產品從vc6遷移到vs2005,結果發現了很多的warning和error

            warning 主要是使用了strcpy,strcat這樣的函數
            這些在2005中都是unsafe_api.
            在vs2005都推薦使用strcpy_s,strcat_s.
            我想微軟這么做固然跟C++ standard有偏差
            但是這些函數的使用確實造成了微軟產品經常有的漏洞
            微軟深受這些函數的危害阿
            所以在vs2005這些都是warning

            error的類型主要是以下幾種,多半和STL有關

            1.include 帶.h的舊式頭文件,比如 #include <iostream.h>改為include <iostream>

            2.vc6的string iterator的 char *,而vs2005中卻不是
            strcpy(s.begin(), str);是不能compile的,應改為strcpy((char *) s.c_str(),str);

            3.函數返回類型不支持缺省是int
            missing type specifier - int assumed. Note: C++ does not support default-int
            <Code>
                extern IsWindowsNT();

            <Fix>
                extern int IsWindowsNT();

            posted on 2005-12-20 08:56 夢在天涯 閱讀(2074) 評論(1)  編輯 收藏 引用 所屬分類: CPlusPlus

            評論

            # re: 移置c++從6.0到2005 2010-02-09 16:25 wantukang

            不錯,先記下,以后有需要再來查看  回復  更多評論   

            公告

            EMail:itech001#126.com

            導航

            統計

            • 隨筆 - 461
            • 文章 - 4
            • 評論 - 746
            • 引用 - 0

            常用鏈接

            隨筆分類

            隨筆檔案

            收藏夾

            Blogs

            c#(csharp)

            C++(cpp)

            Enlish

            Forums(bbs)

            My self

            Often go

            Useful Webs

            Xml/Uml/html

            搜索

            •  

            積分與排名

            • 積分 - 1807602
            • 排名 - 5

            最新評論

            閱讀排行榜

            久久精品成人国产午夜| 一本一道久久综合狠狠老| 久久婷婷五月综合97色一本一本| 东方aⅴ免费观看久久av| 久久香蕉超碰97国产精品| 国产精品久久久久影视不卡| 久久精品国产99国产精品| 久久午夜无码鲁丝片秋霞| 国内精品久久久久影院一蜜桃| 久久精品视频网| 亚洲午夜无码久久久久| 久久99精品久久久久久噜噜| AV无码久久久久不卡蜜桃| 久久精品无码免费不卡| 2022年国产精品久久久久| 一个色综合久久| 91亚洲国产成人久久精品| 狠狠色婷婷久久综合频道日韩 | 亚洲乱码日产精品a级毛片久久| 久久久一本精品99久久精品88| 久久免费视频一区| 亚洲国产二区三区久久| 热re99久久6国产精品免费| 日本高清无卡码一区二区久久 | 久久精品国产亚洲AV不卡| 色成年激情久久综合| 久久久久99精品成人片直播| 国产69精品久久久久观看软件 | 18禁黄久久久AAA片| 无码任你躁久久久久久| 国产免费久久精品99久久| 国产91色综合久久免费| 久久久久久午夜成人影院| 久久人人爽人人爽人人片av高请 | 伊人久久大香线蕉精品| 午夜不卡久久精品无码免费| 久久久久亚洲AV无码观看| 丁香色欲久久久久久综合网| 色婷婷综合久久久中文字幕| 无码专区久久综合久中文字幕| 无码日韩人妻精品久久蜜桃|