yutou's blog

请不要做浮躁的人,请热爱C++。
posts - 14, comments - 1, trackbacks - 0, articles - 0
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2008年4月20日

du8.com的书..很不错..但是要VIP,,,又是VIP

http://pic.du8.com/onlineimg/31/bp/sep/2003/31bp.0001.png

这本书的地址是从这里开始的,,,0002 0003 …0100…N

posted @ 2008-04-20 17:52 yutou 阅读(125) | 评论 (0)编辑 收藏

2008年4月10日

很好的一个小册子,不大不小,却是一个学习的好帮手.放此收藏.

感谢LXH2002的收集整理.              ;-)

posted @ 2008-04-10 22:55 yutou 阅读(229) | 评论 (1)编辑 收藏

2008年4月7日

int i = 0;
int *= &i ,*pk;

pk 
= p;
delete pk;  
//错误
//不能delete一个不是new分配的空间

int i = 0;

new *= &i;
new *pk = p;

delete p;  
//正确
//p与pk指向同一个内存区域,而这个内存区域是由new产生

posted @ 2008-04-07 17:24 yutou 阅读(120) | 评论 (0)编辑 收藏

在if else if 使用中出现的一点问题,编译器报出“在return的前面缺少 ';' ”

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;
}


//更改后通过编译的代码
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;
}

posted @ 2008-04-07 17:06 yutou 阅读(94) | 评论 (0)编辑 收藏

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:标准库相当复杂!

posted @ 2008-04-07 16:58 yutou 阅读(284) | 评论 (0)编辑 收藏

2008年4月6日

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

一个定义为volatile的变量是说这变量可能会被意想不到地改变,这样,编译器就不会去假设这个变量的值了。精确地说就是,优化器在用到这个变量时必须每次都小心地重新读取这个变量的值,而不是使用保存在寄存器里的备份。下面是volatile变量的几个例子:
    1). 并行设备的硬件寄存器(如:状态寄存器)
    2). 一个中断服务子程序中会访问到的非自动变量(Non-automatic variables)
    3). 多线程应用中被几个任务共享的变量
    回答不出这个问题的人是不会被雇佣的。我认为这是区分C程序员和嵌入式系统程序员的最基本的问题。嵌入式系统程序员经常同硬件、中断、RTOS等等打交道,所用这些都要求volatile变量。不懂得volatile内容将会带来灾难。
    假设被面试者正确地回答了这是问题(嗯,怀疑这否会是这样),我将稍微深究一下,看一下这家伙是不是直正懂得volatile完全的重要性。
    1). 一个参数既可以是const还可以是volatile吗?解释为什么。
    2). 一个指针可以是volatile 吗?解释为什么。
    3). 下面的函数有什么错误:
         int square(volatile int *ptr)
         {
              return *ptr * *ptr;
         }
    下面是答案:
    1). 是的。一个例子是只读的状态寄存器。它是volatile因为它可能被意想不到地改变。它是const因为程序不应该试图去修改它。
    2). 是的。尽管这并不很常见。一个例子是当一个中服务子程序修该一个指向一个buffer的指针时。
    3). 这段代码的有个恶作剧。这段代码的目的是用来返指针*ptr指向值的平方,但是,由于*ptr指向一个volatile型参数,编译器将产生类似下面的代码:
    int square(volatile int *ptr) 
    {
         int a,b;
         a = *ptr;
         b = *ptr;
         return a * b;
     }
    由于*ptr的值可能被意想不到地该变,因此a和b可能是不同的。结果,这段代码可能返不是你所期望的平方值!正确的代码如下:
     long square(volatile int *ptr) 
     {
            int a;
            a = *ptr;
            return a * a;
     }

posted @ 2008-04-06 17:29 yutou 阅读(136) | 评论 (0)编辑 收藏

2008年3月10日

By SmartPtr(http://www.cppblog.com/SmartPtr/)

这几天工作时碰到一个C++的编译错误(我使用的是Visual C++ 7.0),说是有一个类重复定义,仔细想想我们的这个项目也是做了好几个Release了, 内部代码应该不会有这样的低级错误, 真把类型给重复定义了,检查结果正如我预料的一样。 就这样, 我左右没找到原因,被一个编译错误给卡在那里了。(在我的概念中, 程序错误的等级为:编译错误->链接错误->逻辑错误, 此错误属于最低级 )。这时我仔细看了一下错误提示, 发现重复定义是由于从两个不同的路径包含了同一个头文件而引起的,同事也建议从另外一个路径打开工程试试, 这才慢慢发现了原因。这个原因可能有些拗口,而事实上要出现这种错误也有些曲折 让我从不同情况下的类型重定义来解释一下吧。

我总结的C++中类型重定义情况有三。

1 没有在文件头加#pragma once指示符。

Type1.h:  #pragma once的作用是保证本文件只被编译一次,如果没有在Type1.h中加这句话那么在main.cpp里面包含了两次Type1.h 就相当于在main.cpp里面定义了两次Type类, 自然就是类型重定义了。

//#pragma once
class Type
{
}
;

Main.cpp:
#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
{     

}
;


这里main.cpp中同时包含了Type1.h, Type2.h两个头文件, 虽然其文件头都有#pragma once,但因为是不同的文件, 预编译器还是会两次把Type类的定义放在Main.cpp中, 所以也会出现了重定义。

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


3 从两个不同的路径包含了同一个头文件

  前面两种是比较常见, 也是比较容易解决的情况, 而这里要讲的第三种情况, 比较少见, 而且一般出现在有虚拟映射盘的时候。(这样才能做到从两个不同的路径包含同一个头文件), 其他会在什么时候出现, 我还没想到, 知道的朋友顶一下:)。下面我来分析一下:
1 VC工程在D:\Test目录下。
2 映射虚拟盘XD:\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 在包含头文件时,不要使用绝对路径, 哪怕那是虚拟盘的绝对路径。

posted @ 2008-03-10 16:32 yutou 阅读(340) | 评论 (0)编辑 收藏

yutou

2008年3月10日

如图:    需求分析 => 可行性分析 => 实施具体方案 => 维护与支持

posted @ 2008-03-10 00:11 yutou 阅读(102) | 评论 (0)编辑 收藏

2008年3月9日

用可行性研究论证您的项目

 

Scott W. Ambler
总裁,Ronin International
2000
8 24
本文来自 http://www.ibm.com/developerworks/tw/library/tip-justify/



               在任何项目的开始阶段,项目组都要为项目的总体工作做一些准备工作。在 Rational Unified ProcessRUP)和面向对象的软件过程(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 TechnologyScott W. Ambler 著。Cambridge University 出版社,纽约,1998 年。

· More Process Patterns — Delivering Large-Scale Systems Using Object TechnologyScott W. Ambler 著。Cambridge University 出版社,纽约,1999 年。

· The Object Primer 2nd EditionScott W. Ambler 著。Cambridge University 出版社,纽约,2000 年。

· The Unified Process Inception PhaseScott W. Ambler Larry L. Constantine 著。R&D BooksCAGilroy2000 年。

· The Unified Process Elaboration PhaseScott W. Ambler Larry L. Constantine 著。R&D BooksCAGilroy2000 年。

· Patterns of Software Systems Failure and SuccessCapers Jones 著。International Thomson Computer 出版社,MABoston1996 年。

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

· The Squandered Computer: Evaluating the Business Alignment of Information TechnologiesPaul Strassmann 著。New CanaanCTInformation Economics 出版社,CTNew Canaan1997 年。

· The Process Patterns Resource PageScott Ambler

· Scott Ambler 的在线文章


/*  &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&  */
1. 论证阶段的过程模型(译)

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

posted @ 2008-03-09 23:45 yutou 阅读(2821) | 评论 (0)编辑 收藏

2008年3月4日

“我近三十年来一直在学习马克思主义哲学,并总是试图用马克思主义哲学指导我的工作。马克思主义是智慧的源泉。”      --钱学森在给一位朋友的信中这样说道

马克思主义哲学对一个人的思想有着革命性的意义.

blog之,提醒自己不要忽视哲学,并且鞭策自己要坚持学习!

posted @ 2008-03-04 13:30 yutou 阅读(105) | 评论 (0)编辑 收藏