yutou's blog

code:

//出現error C2440
bool is_equal( const vector <int> &ivec )  //vector對象的常引用
{
     for( vector <int>::iterator it = ivec.begin() ;it != ivec.end() ;++it )  //這里使用的是iterator
       {
            ……
        }
}

//正確的使用方法
bool is_equal( const vector <int> &ivec )  //vector對象的常引用
{
     for( vector <int>::const_iterator it = ivec.begin() ;it != ivec.end() ;++it )  //這里使用的是const_iterator
       {
            ……
        }
}

ps:標準庫相當復雜！

信息來源:http://blog.21ic.com/user1/2949/archives/2007/35599.html

我總結的C++中類型重定義情況有三。

1 沒有在文件頭加#pragma once指示符。

Type1.h:  #pragma once的作用是保證本文件只被編譯一次，如果沒有在Type1.h中加這句話，那么在main.cpp里面包含了兩次Type1.h， 就相當于在main.cpp里面定義了兩次Type類， 自然就是類型重定義了。

//#pragma once
class Type
{
};

#include "Type1.h"
#include "Type1.h"
int main(int argc, char *argv[])
{
   return 1;
}

2 兩個不同的頭文件中定義了相同的類型（均有#pragma once）

Type1.h:Type2.h:Main.cpp:

#pragma once
class Type
{

};

#pragma once
class Type
{     

};

所以也會出現了重定義。

#include "Type1.h"
#include "Type2.h"
int main(int argc, char *argv[])
{
   return 1;
}

3 從兩個不同的路徑包含了同一個頭文件

  前面兩種是比較常見， 也是比較容易解決的情況， 而這里要講的第三種情況， 比較少見， 而且一般出現在有虛擬映射盤的時候。（這樣才能做到從兩個不同的路徑包含同一個頭文件）， 其他會在什么時候出現， 我還沒想到， 知道的朋友頂一下：）。下面我來分析一下：
1） 有VC工程在D:\Test目錄下。
2） 映射虛擬盤X為D:\Test.
不熟悉的網友可以按此操作: 開始->運行->在運行窗口輸入：cmd->在cmd窗口輸入：
Subst X: D:\Test->回車。
3） 該工程有文件Type1.h, main.cpp

Type1.h:

#pragma once
class Type
{

};

Main.cpp:

main.cpp這樣包含了兩個頭文件， 從本質上來講， 它們都對應于物理盤D:\Test下的文件Type1.h, 是同一個文件。但在不同的操作下， VC對其有不同的解釋。#include "X:\Type1.h"用的是絕對路徑， 自然沒有什么異議， 但#include "Type1.h"卻有些變化:
*假如我從D:\Test\下打開工程， 那么#include "Type1.h"其實就是#include "D:\Test\Type1.h"
*假如從X:\下打開工程，那么#include "Type1.h"就解釋為#include "X:\Type1.h"

#include "Type1.h"
#include "X:Type1.h"
int main(int argc, char *argv[])
{
   return 1;
}

這里我們在

4） 在D:\Test下打開工程， 編譯， 出現類型Type重復定義錯誤

這種情況下，main.cpp預編譯為:

Main.cpp:

只保證本文件被編譯一次， 這里VC將其認為是兩個不同的文件， 所以都要編譯， 出現編譯錯誤自然也就不奇怪了。
    當然， 這里如果從X:\ 下打開工程的話，VC就會認為都是從X:\Type1.h下包含這個文件，#pragma once起到了作用， 也就不會出現類型重定義了

#include "D:TestType1.h"
#include "X:Type1.h"
int main(int argc, char *argv[])
{
   return 1;
}

 

#pragma once

總結

我在VC7, VC8,和Dev C++中都測試了第三種情況， 發現只有Dev C++是可以通過編譯的。這可能是微軟VC的#pragma once還不夠智能吧，輕易的被Windows的虛擬盤給蒙蔽了雙眼， 看不到其本質（只是猜測， 或許VC這么處理是有其他用意的）。

因為在稍大一點的工程開發中， 我們一般都會用虛擬盤來方便工作， 一是訪問快捷，簡化了路徑， 二是因為多人協同開發，我們一般希望大家源代碼路徑相同，但我們不應強制要求大家都把源代碼放死在某一目錄下， 這時把你放源代碼的路徑映射為一個虛擬盤（比如說統一為X:）就能把大家的代碼路徑統一起來了。但是另一方面，有了虛擬盤， 就為出現類型重定義提供了條件， 以下是我得出的兩個解決方法：

1 拋棄#pragma once使用古老但集穩定性與移植性于一身的

來保證頭文件只被編譯一次。這樣不管是包含兩個相同的文件，還是包含兩個不同的文件，或是包兩個文件相同但路徑不同的文件， 只要_XXX_H被定義過， 就不會再編譯那個編譯(但這里我們要保證_XXX_H的唯一性， 如果兩個不同的頭文件里用了同一_XXX_H,是會出問題的)

 

#ifndef _XXX_H
#define _XXX_H


#endif

2 在包含頭文件時，不要使用絕對路徑， 哪怕那是虛擬盤的絕對路徑。

yutou

2008年3月10日

用可行性研究論證您的項目

Scott W. Ambler
總裁，Ronin International
2000 年8 月24 日
本文來自 http://www.ibm.com/developerworks/tw/library/tip-justify/

               在任何項目的開始階段，項目組都要為項目的總體工作做一些準備工作。在 Rational Unified Process（RUP）和面向對象的軟件過程（OOSP）中，這個階段稱為啟動階段。本周，我們考慮如何確定一個項目是否值得啟動。本文由《Process Patterns》的第五章改編而來。

               啟動項目的一個重要環節就是對項目進行論證；也就是說，確定是否應該立項。遺憾的是，論證經常是完成得最差的一項任務。85% 以上的大型項目以失敗告終（請參閱參考資源中的《Patterns of Software Systems Failure and Success》一書），這一事實表明大多數項目在論證階段就應該中止，而不是在為其作了大量投資（并造成損失）之后。論證階段的主要目標是，確定項目的最佳實施方案，如果存在這樣的方案，還要論證它為什么是最佳的。

               圖1描繪了針對論證階段的過程模型的解決方案。論證項目時需要完成幾項工作，論證項目的主要結果便是可行性研究。為了進行可行性研究，您將重復下列步驟：

           · 確定可選的實施方案

           · 評估每項可選方案的經濟可行性

           · 評估每項可選方案的技術可行性

           · 評估每項可選方案的運行可行性

           · 選擇一項可選方案

           · 確定潛在的風險

圖 1. 論證階段的過程模型

確定可選的實施方案

可行性研究的第一階段是確定項目潛在的可選實施方案。與流行的觀點正好相反，實現應用時總有多種選擇，包括什么都不做、使用多種技術實現它、購買一種類似的系統或者將開發工作外包。重要的是，為您的項目確定幾個可行的可選實施方案，以便您進行評估和比較，從而最終為自己的公司選擇最佳的實施方案。

評估經濟可行性
在評估一項可選實施方案的經濟可行性時，要回答的基本問題是，“該應用何時能收回成本？”您可以通過進行成本/收益分析來回答這個問題。顧名思義，成本/收益分析就是將應用的全部實際成本與其全部實際財務收益相比較。在《The Squandered Computer》一書中（請參閱參考資源），Strassmann 指出，應該根據可選方案對凈現金流量 — 即收益超過成本的總金額 — 的貢獻來評價各個方案，因為所有投資的首要目標就是提高公司的整體業績。

評估技術可行性
除了經濟可行性之外，您還必須確定每項可選實施方案的技術可行性。此時需要回答的基本問題是，“是否能夠創建該應用？”首先，您必須調研該項目要使用的各項技術。技術方面的問題在于，每項技術在行銷演示中都能完美地完成工作，而一旦將它購買回來，往往又是另一種情況。因此，您應該鑒定每一種可供選擇的技術。請注意，為了進行合理的評估，您可能需要實現一個微型項目，并且創建一個概念驗證 (proof-of-concept) 原型來檢驗這些技術是否能協同工作。這是 RUP 的描述階段的基本任務，它可能持續幾周或者幾個月，但是只有在檢驗出您選擇的技術能否協同工作時才會體現出它的價值。

評估運行可行性
一個應用不應該在經濟和技術上行得通，它還必須在運行上行得通。此時要回答的問題的，“應用一旦成為產品，是否能夠對該應用提供維護和支持？”創建一個應用與運行一個應用完全是兩碼事；因此，您必須確定是否能夠有效地運行和支持它。

選擇一項可選方案
一旦完成對每項可選實施方案的經濟、技術和運行可行性評估，就應該從中選擇一種實施方案。請記住 — 可行性研究的目標是，比較和對比各項可選實施方案，并提出一個最佳的實施方案。執行該項任務的第一步是，排除任何在經濟上、技術上或者運行上不可行的方案。這意味著您可能沒有剩下任何可選方案。但是什么都不做可能也是不可行的，它意味著您必須從頭再來，鑒定更多的可選方案。如果只剩下一個可選方案，則很容易做出決策；如果最后剩下多個可選方案，則必須選擇一個最適合您的公司的實施方案。您還可以只確定可行的可選方案，而將決策權留給上級主管部門。

確定潛在的風險
項目論證工作包括定義潛在的風險，特別是那些與項目的技術和運行可行性相關的潛在風險。關鍵的一點是應該將它們加入您的風險評估文檔，以便在項目實施過程中能夠妥善處理它們，這也是今后的技巧要討論的主題。

參考資源
關于過程模型和 Rational Unified Process 的詳細信息，請參閱：

· 《Process Patterns — Building Large-Scale Systems Using Object Technology》，Scott W. Ambler 著。Cambridge University 出版社，紐約，1998 年。

· 《More Process Patterns — Delivering Large-Scale Systems Using Object Technology》，Scott W. Ambler 著。Cambridge University 出版社，紐約，1999 年。

· 《The Object Primer 2nd Edition》，Scott W. Ambler 著。Cambridge University 出版社，紐約，2000 年。

· 《The Unified Process Inception Phase》，Scott W. Ambler 和 Larry L. Constantine 著。R&D Books，CA，Gilroy，2000 年。

· 《The Unified Process Elaboration Phase》，Scott W. Ambler 和 Larry L. Constantine 著。R&D Books，CA，Gilroy，2000 年。

· 《Patterns of Software Systems Failure and Success》，Capers Jones 著。International Thomson Computer 出版社，MA，Boston，1996 年。

· 《The Rational Unified Process: An Introduction》，第二版，Philippe Kruchten 著。Reading, MA: Addison-Wesley Longman, Inc.，MA，Reading，2000 年。

· 《The Squandered Computer: Evaluating the Business Alignment of Information Technologies》，Paul Strassmann 著。New Canaan，CT：Information Economics 出版社，CT，New Canaan，1997 年。

· 《The Process Patterns Resource Page》，Scott Ambler 著

· Scott Ambler 的在線文章

/*  &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&  */
圖 1. 論證階段的過程模型(譯)

方案文檔,                                                                                                                           可行性研究,
版本,                                                  評估運行可行性   風險評估                                建議,
方案評估,    => 論證執行方案 =>                                       =>  選擇一種方案 =>   項目資金,
進度表,                                              評估經濟可行性   評估技術可行性                   確定潛在風險
風險估計