??xml version="1.0" encoding="utf-8" standalone="yes"?>
http://pic.du8.com/onlineimg/31/bp/sep/2003/31bp.0001.png
q本书的地址是从q里开始的,,,0002 0003 …0100…N
]]>
感谢LXH2002的收集整? ;-)
]]>int i = 0;
int *p = &i ,*pk;
pk = p;
delete pk; //错误
//不能delete一个不是new分配的空?br>
int i = 0;
new *p = &i;
new *pk = p;
delete p; //正确
//p与pk指向同一个内存区域,而这个内存区域是由new产生
]]>
int compare( int shu_size ,const vector <int> &_vec )
{
int vec_size = int(_vec.size());
if( shu_size == vec_size ) return shu_size;
else if( shu_size < vec_size ) return shu_size;
else ( shu_size > vec_size ) return vec_size;
}
//更改后通过~译的代?br>
int compare( int shu_size ,const vector <int> &_vec )
{
int vec_size = int(_vec.size());
if( shu_size == vec_size ) vec_size = shu_size;
return vec_size;
}
]]>
ps:标准库相当复杂!
我ȝ的C++中类型重定义情况有三?/span>
1 没有在文件头?/span>#pragma once指示W?br>
Type1.h: #pragma once的作用是保证本文件只被编译一ơ,如果没有?/span>Type1.h中加q句?/span>Q?/span>那么?/span>main.cpp里面包含了两?/span>Type1.hQ?/span> q当于?/span>main.cpp里面定义了两?/span>Typec, 自然是cd重定义了?/span>
2 两个不同的头文g中定义了相同的类型(均有#pragma onceQ?br>
Type1.h:
3 从两个不同的路径包含了同一个头文g
前面两种是比较常见, 也是比较Ҏ(gu)解决的情况, 而这里要讲的W三U情况, 比较?yu)见Q?/span> 而且一般出现在有虚拟映盘的时候。(q样才能做到从两个不同的路径包含同一个头文gQ, 其他?x)在什么时候出玎ͼ 我还没想刎ͼ 知道的朋友顶一下:(x)Q。下面我来分析一下:(x)
1Q?/span> ?/span>VC工程?/span>D:\Test目录下?br>2Q?/span> 映射虚拟?/span>X?/span>D:\Test.
不熟(zhn)的|友可以按此操作: 开?/span>->q行->在运行窗口输入:(x)cmd->?/span>cmdH口输入Q?br>Subst X: D:\Test->回R?br>3Q?/span> 该工E有文gType1.h, main.cpp
Type1.h:
Main.cpp:
main.cppq样包含了两个头文gQ?/span> 从本质上来讲Q?/span> 它们都对应于物理?/span>D:\Test下的文gType1.h, 是同一个文件?/span>但在不同的操作下Q?/span> VC对其有不同的解释?/span>#include "X:\Type1.h"用的是绝对\径, 自然没有什么异议, ?/span>#include "Type1.h"却有些变?/span>:
*假如我从D:\Test\下打开工程Q?/span> 那么#include "Type1.h"其实是#include "D:\Test\Type1.h"
*假如?/span>X:\下打开工程Q那?/span>#include "Type1.h"p释ؓ(f)#include "X:\Type1.h"
4Q?/span> ?/span>D:\Test下打开工程Q?/span> ~译Q?/span> 出现cdType重复定义错误
q种情况下,main.cpp预编译ؓ(f):
Main.cpp:
只保证本文g被编译一ơ, q里VC其认ؓ(f)是两个不同的文gQ?/span> 所以都要编译, 出现~译错误自然也就不奇怪了?br> 当然Q?/span> q里如果?/span>X:\ 下打开工程的话Q?/span>VC׃(x)认ؓ(f)都是?/span>X:\Type1.h下包含这个文Ӟ#pragma once起到了作用, 也就不会(x)出现cd重定义了
#pragma once
我在VC7, VC8,?/span>Dev C++中都试了第三种情况Q?/span> 发现只有Dev C++是可以通过~译的。这可能是微?/span>VC?/span>#pragma onceq不够智能吧Q轻易的?/span>Windows的虚拟盘l蒙蔽了双眼Q?/span> 看不到其本质Q只是猜, 或许VCq么处理是有其他用意的)?/span>
因ؓ(f)在稍大一点的工程开发中Q?/span> 我们一般都?x)用虚拟盘来方便工作Q?/span> 一是访问快P化了路径Q?/span> 二是因ؓ(f)多h协同开发,我们一般希望大家源代码路径相同Q但我们不应强制要求大家都把源代码放d某一目录下, q时把你放源代码的\径映ؓ(f)一个虚拟盘Q比如说l一?/span>X:Q就能把大家的代码\径统一h了。但是另一斚wQ有了虚拟盘Q?/span> ׃ؓ(f)出现cd重定义提供了条gQ?/span> 以下是我得出的两个解x法:(x)
1 抛弃#pragma once使用古老但集稳定性与UL性于一w的
来保证头文g只被~译一ơ。这样不是包含两个相同的文Ӟq是包含两个不同的文Ӟ或是包两个文件相同但路径不同的文Ӟ 只要_XXX_H被定义过Q?׃?x)再~译那个~译(但这里我们要保证_XXX_H的唯一性, 如果两个不同的头文g里用了同一_XXX_H,是会(x)出问题的)
Scott W. Ambler
总裁Q?/span>Ronin International
2000 q?/span>8 ?/span>24 ?/span>
本文来自 http://www.ibm.com/developerworks/tw/library/tip-justify/
在Q何项目的开始阶D,目l都要ؓ(f)目的M工作做一些准备工作。在 Rational Unified ProcessQ?/span>RUPQ和面向对象的Y件过E(OOSPQ中Q这个阶D늧为启动阶Dc(din)本周,我们考虑如何定一个项目是否值得启动。本文由?/span>Process Patterns》的W五章改~而来?/span>
启动目的一个重要环节就是对目q行Q也是_(d)定是否应该立项。遗憄是,l常是完成得最差的一Q务?/span>85% 以上的大型项目以p|告终Q请参阅参考资?/span>中的?/span>Patterns of Software Systems Failure and Success》一书)Q这一事实表明大多数项目在阶段应该中止,而不是在为其作了大量投资Qƈ造成损失Q之后。论证阶D늚主要目标是,定目的最?jng)_施方案,如果存在q样的方案,q要它ؓ(f)什么是最佳的?/span>
?/span>1描绘了针对论证阶D늚q程模型的解x案。论证项目时需要完成几工作,目的主要结果便是可行性研I。ؓ(f)了进行可行性研IӞ(zhn)将重复下列步骤Q?/span>
?/span> 1. 阶段的过E模?/span>
定可选的实施Ҏ(gu)
可行性研I的W一阶段是确定项目潜在的可选实施方案。与行的观Ҏ(gu)好相反,实现应用时L多种选择Q包括什么都不做、用多U技术实现它、购CU类似的pȝ或者将开发工作外包。重要的是,为?zhn)的项目确定几个可行的可选实施方案,以便(zhn)进行评估和比较Q从而最lؓ(f)自己的公叔R择最佳的实施Ҏ(gu)?/span>
评估l济可行?/span>
在评C可选实施方案的l济可行性时Q要回答的基本问题是Q?/span>“该应用何时能收回成本Q?/span>”(zhn)可以通过q行成本/收益分析来回{这个问题。顾名思义Q成?/span>/收益分析是应用的全部实际成本与其全部实际财务收益相比较。在?/span>The Squandered Computer》一书中Q请参阅参考资?/span>Q,Strassmann 指出Q应该根据可选方案对净现金量 ?x益超q成本的总金?/span> ?的A(ch)献来评h(hun)各个Ҏ(gu)Q因为所有投资的首要目标是提高公司的整体业l?/span>
评估技术可行?/span>
除了l济可行性之外,(zhn)还必须定每项可选实施方案的技术可行性。此旉要回{的基本问题是,“是否能够创徏该应用?”首先Q?zhn)必须调研该项目要使用的各?gu)术。技术方面的问题在于Q每Ҏ(gu)术在行销演示中都能完地完成工作Q而一旦将它购买回来,往往又是另一U情c(din)因此,(zhn)应该鉴定每一U可供选择的技术。请注意Qؓ(f)了进行合理的评估Q?zhn)可能需要实C个微型项目,q且创徏一个概念验?/span> (proof-of-concept) 原型来检验这些技术是否能协同工作。这?/span> RUP 的描q阶D늚基本dQ它可能持箋几周或者几个月Q但是只有在(g)验出(zhn)选择的技术能否协同工作时才会(x)体现出它的h(hun)倹{?/span>
评估q行可行?/span>
一个应用不应该在经和技术上行得通,它还必须在运行上行得通。此时要回答的问题的Q?/span>“应用一旦成Z品,是否能够对该应用提供l护和支持?”创徏一个应用与q行一个应用完全是两码事;因此Q?zhn)必须定是否能够有效地运行和支持它?/span>
选择一可选方?/span>
一旦完成对每项可选实施方案的l济、技术和q行可行性评伎ͼ应该从中选择一U实施方案。请C ?可行性研I的目标是,比较和对比各可选实施方案,q?/em>提出一个最佳的实施Ҏ(gu)。执行该Q务的W一步是Q排除Q何在l济上、技术上或者运行上不可行的Ҏ(gu)。这意味着(zhn)可能没有剩下Q何可选方案。但是什么都不做可能也是不可行的Q它意味着(zhn)必M头再来,鉴定更多的可选方案。如果只剩下一个可选方案,则很Ҏ(gu)做出决策Q如果最后剩下多个可选方案,则必选择一个最适合(zhn)的公司的实施方案。?zhn)q可以只定可行的可选方案,而将决策权留l上U主部门?/span>
定潜在的风?/span>
目工作包括定义潜在的风险,特别是那些与目的技术和q行可行性相关的潜在风险。关键的一Ҏ(gu)应该它们加入?zhn)的风险评估文档,以便在项目实施过E中能够妥善处理它们Q这也是今后的技巧要讨论的主题?/span>
参考资?/span>
关于q程模型?/span> Rational Unified Process 的详l信息,请参阅:(x)
· ?/span>Process Patterns ?Building Large-Scale Systems Using Object Technology?/span>Q?/span>Scott W. Ambler 著?/span>Cambridge University 出版C,U约Q?/span>1998 q?/span>
· ?/span>More Process Patterns ?Delivering Large-Scale Systems Using Object Technology?/span>Q?/span>Scott W. Ambler 著?/span>Cambridge University 出版C,U约Q?/span>1999 q?/span>
· ?/span>The Object Primer 2nd Edition?/span>Q?/span>Scott W. Ambler 著?/span>Cambridge University 出版C,U约Q?/span>2000 q?/span>
· ?/span>The Unified Process Inception Phase?/span>Q?/span>Scott W. Ambler ?/span> Larry L. Constantine 著?/span>R&D BooksQ?/span>CAQ?/span>GilroyQ?/span>2000 q?/span>
· ?/span>The Unified Process Elaboration Phase?/span>Q?/span>Scott W. Ambler ?/span> Larry L. Constantine 著?/span>R&D BooksQ?/span>CAQ?/span>GilroyQ?/span>2000 q?/span>
· ?/span>Patterns of Software Systems Failure and Success?/span>Q?/span>Capers Jones 著?/span>International Thomson Computer 出版C,MAQ?/span>BostonQ?/span>1996 q?/span>
· ?/span>The Rational Unified Process: An Introduction》,W二版,Philippe Kruchten 著?/span>Reading, MA: Addison-Wesley Longman, Inc.Q?/span>MAQ?/span>ReadingQ?/span>2000 q?/span>
· ?/span>The Squandered Computer: Evaluating the Business Alignment of Information Technologies?/span>Q?/span>Paul Strassmann 著?/span>New CanaanQ?/span>CTQ?/span>Information Economics 出版C,CTQ?/span>New CanaanQ?/span>1997 q?/span>
· ?/span>The Process Patterns Resource Page?/span>Q?/span>Scott Ambler ?/span>
/* &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& */
?/span> 1. 阶段的过E模??
Ҏ(gu)文档, 可行性研I?
版本, 评估q行可行?nbsp; 风险评估 ,
Ҏ(gu)评估, => 执行Ҏ(gu) => => 选择一U方?=> 目资金,
q度? 评估l济可行?nbsp; 评估技术可行?nbsp; 定潜在风险
风险估计