code:

//出現(xiàn)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:標(biāo)準(zhǔn)庫相當(dāng)復(fù)雜！

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

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

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

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

//#pragma once
class Type
{
};

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

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

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

#pragma once
class Type
{

};

#pragma once
class Type
{     

};

，但因?yàn)槭遣煌奈募?/span> 預(yù)編譯器還是會(huì)兩次把Type類的定義放在Main.cpp中， 所以也會(huì)出現(xiàn)了重定義。

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

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

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

Type1.h:

#pragma once
class Type
{

};

Main.cpp:

main.cpp這樣包含了兩個(gè)頭文件， 從本質(zhì)上來講， 它們都對應(yīng)于物理盤D:\Test下的文件Type1.h, 是同一個(gè)文件。但在不同的操作下， VC對其有不同的解釋。#include "X:\Type1.h"用的是絕對路徑， 自然沒有什么異議， 但#include "Type1.h"卻有些變化:
*假如我從D:\Test\下打開工程， 那么#include "Type1.h"其實(shí)就是#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下打開工程， 編譯， 出現(xiàn)類型Type重復(fù)定義錯(cuò)誤

這種情況下，main.cpp預(yù)編譯為:

Main.cpp:

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

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

 

#pragma once

總結(jié)

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

因?yàn)樵谏源笠稽c(diǎn)的工程開發(fā)中， 我們一般都會(huì)用虛擬盤來方便工作， 一是訪問快捷，簡化了路徑， 二是因?yàn)槎嗳藚f(xié)同開發(fā)，我們一般希望大家源代碼路徑相同，但我們不應(yīng)強(qiáng)制要求大家都把源代碼放死在某一目錄下， 這時(shí)把你放源代碼的路徑映射為一個(gè)虛擬盤（比如說統(tǒng)一為X:）就能把大家的代碼路徑統(tǒng)一起來了。但是另一方面，有了虛擬盤， 就為出現(xiàn)類型重定義提供了條件， 以下是我得出的兩個(gè)解決方法：

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

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

 

#ifndef _XXX_H
#define _XXX_H


#endif

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

yutou

2008年3月10日

用可行性研究論證您的項(xiàng)目

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

               在任何項(xiàng)目的開始階段，項(xiàng)目組都要為項(xiàng)目的總體工作做一些準(zhǔn)備工作。在 Rational Unified Process（RUP）和面向?qū)ο蟮能浖^程（OOSP）中，這個(gè)階段稱為啟動(dòng)階段。本周，我們考慮如何確定一個(gè)項(xiàng)目是否值得啟動(dòng)。本文由《Process Patterns》的第五章改編而來。

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

               圖1描繪了針對論證階段的過程模型的解決方案。論證項(xiàng)目時(shí)需要完成幾項(xiàng)工作，論證項(xiàng)目的主要結(jié)果便是可行性研究。為了進(jìn)行可行性研究，您將重復(fù)下列步驟：

           · 確定可選的實(shí)施方案

           · 評估每項(xiàng)可選方案的經(jīng)濟(jì)可行性

           · 評估每項(xiàng)可選方案的技術(shù)可行性

           · 評估每項(xiàng)可選方案的運(yùn)行可行性

           · 選擇一項(xiàng)可選方案

           · 確定潛在的風(fēng)險(xiǎn)

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

確定可選的實(shí)施方案

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

評估經(jīng)濟(jì)可行性
在評估一項(xiàng)可選實(shí)施方案的經(jīng)濟(jì)可行性時(shí)，要回答的基本問題是，“該應(yīng)用何時(shí)能收回成本？”您可以通過進(jìn)行成本/收益分析來回答這個(gè)問題。顧名思義，成本/收益分析就是將應(yīng)用的全部實(shí)際成本與其全部實(shí)際財(cái)務(wù)收益相比較。在《The Squandered Computer》一書中（請參閱參考資源），Strassmann 指出，應(yīng)該根據(jù)可選方案對凈現(xiàn)金流量 — 即收益超過成本的總金額 — 的貢獻(xiàn)來評價(jià)各個(gè)方案，因?yàn)樗型顿Y的首要目標(biāo)就是提高公司的整體業(yè)績。

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

評估運(yùn)行可行性
一個(gè)應(yīng)用不應(yīng)該在經(jīng)濟(jì)和技術(shù)上行得通，它還必須在運(yùn)行上行得通。此時(shí)要回答的問題的，“應(yīng)用一旦成為產(chǎn)品，是否能夠?qū)υ搼?yīng)用提供維護(hù)和支持？”創(chuàng)建一個(gè)應(yīng)用與運(yùn)行一個(gè)應(yīng)用完全是兩碼事；因此，您必須確定是否能夠有效地運(yùn)行和支持它。

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

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

參考資源
關(guān)于過程模型和 Rational Unified Process 的詳細(xì)信息，請參閱：

· 《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. 論證階段的過程模型(譯)

方案文檔,                                                                                                                           可行性研究,
版本,                                                  評估運(yùn)行可行性   風(fēng)險(xiǎn)評估                                建議,
方案評估,    => 論證執(zhí)行方案 =>                                       =>  選擇一種方案 =>   項(xiàng)目資金,
進(jìn)度表,                                              評估經(jīng)濟(jì)可行性   評估技術(shù)可行性                   確定潛在風(fēng)險(xiǎn)
風(fēng)險(xiǎn)估計(jì)