//出现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:标准库相当复杂！

我总结的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 在包含头文件时，不要使用绝对路径， 哪怕那是虚拟盘的绝对路径。

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. 论证阶段的过程模型(译)

方案文档,                                                                                                                           可行性研究,
版本,                                                  评估运行可行性   风险评估                                建议,
方案评估,    => 论证执行方案 =>                                       =>  选择一种方案 =>   项目资金,
进度表,                                              评估经济可行性   评估技术可行性                   确定潜在风险
风险估计