博文
程序点滴--开放性思维(2)(2007-11-27 22:39:00)
摘要：保证程序可预测性
设计程序的时候，如何保证可预测性呢？答案就是我们上面所说的，所有的代码必须是经过测试的，必须是一步一步调试过的。只有经过你调试过的代码，你才能知道这个代码做某种运算的时候，它是怎样的执行方法。如果你不知道它的执行方法，你没进行过调试，则你就没有任何预测性。要达到可预测性，代码在汇编级是怎么执行的，你都得非常清楚。代码对哪个部分进行了什么操作，你都得知道。如果达不到这点，你的可预测性就很差。
比如，有些程序，你看它的C或者C++的源代码时，都看不出任何的问题。你看静态的程序时看不出任何问题，动态的程序调试你也看不出任何问题，这时，你必须把它的汇编打开，看一看它具体的操作，才能知道。所以说，开放性思维非常重要，你必须从最低层到最上层都要清楚。VC本身提供了一个汇编的调试环境，但是打开汇编后，如果你都看不懂，那你说怎么调呢？调什么？如果一个程序经过调试出来，则它会出错的地方你马上就会知道，只要看一些表现，就知道它有些什么问题。
比如说，我们做“大眼睛”的时候有个这样的现象。当要显示一个很大的图的时候，屏幕上只能显示其中的一小块，这样就可能需要拖动整个图像，但是拖的时候，如果在Windows 2000或Windows XP系统下就会发现，一旦我将图像拖到右下角时，图像就一下到左上角去了。该图像在右下角没有到底的时候还是显示正确的，但一旦到底，就把右下角转到左上角去了，如图1.2所示。
这是怎么回事？在Windows 98和Windows 95下，从来没有这个问题，而且如果图像不到右下角这一行，只差一点，它也不会出现这样的问题。为什么在Windows 98下没有这样的问题，在Windows 2000下会有呢？难道是我的程序有问题？
图1.2 图像显示问题示意图
这时，我就做了一个区域的比较，即看这个区域和整个这个图像的区域，是否中间运算有错误。但程序是调用Windows本身的API，我就怀疑是不是这个API出问题了。于是又重新写了一个区域相交部分，一步一步去查它，也没有任何问题，在任何情况下都是好的，但是到达右下角时，图像就会翻过来。经过以上两个步骤后，我就能确定，这是Windows操作系统的问题，Windows 98下没有这个问题，Windows 2000有，Wind......
程序点滴--开放性思维(1)(2007-11-27 22:38:00)
摘要：要具备开放性思维，就必须了解包括从CPU的执行方法，到Windows平台的运转，到你的程序的调试，最后到你要实现的功能这一整套的内容，只有做到这样，才能真正提高。如果你的知识范围很窄，什么也不了解，纯粹只了解语言，那你的思维就会很狭隘，就会只想到这个语言有这个函数，那个语言没有那个函数，这个C++有这个类，那个语言没有这个类等。而真正要做一个系统，思维一定要是全面的，游离于平台之上的系统和实际的应用软件是不现实的。
这种所谓理想化，已经有很多人提出是不现实的。所以，任何一个软件一定都是跟一个平台相关联的，脱离平台之上的软件几乎都是不能用的。这就必须对平台的本身非常了解。如果你有平台这些方面的知识，这样在思考一个问题的时候，能马上想到操作系统能提供些什么功能，我再需要做些什么，然后就能达到这个目标。这就是一种开放的思维。
在开放的思维下，我要做这个程序的时候，就会考虑怎么把它拆成几个独立的、分开的模块，最简单的，怎么把这个模块尽量能单独调用，而不是我要做个很大的EXE程序。一个很普通的程序员，如果他能够考虑到将程序分成好几个动态库，那么它的思维就已经有点开放性了，就已经不是MFC那些思维方式了。思考问题的时候能把它拆开，就是说，任何一个问题，如果你能把它拆开来思考，这就是简单的开放性思维。
但光会拆还是不够的，尽管有很多人连拆都不会。很多教科书中的程序，要解决问题的时候，就一个main，以后就是一个非常长的函数。这个main函数把所有的事情都解决了。如果连函数都不会分的话，则就是典型的封闭式思维。
这样的人不是没有，我是碰见过的。一些毕业生做的程序就有这种情况。所有的问题都由一个函数来解决。他就不会把它拆成几个模块。我问他，把一件工作拆成几件模块不是更清晰吗？他说，拆出来后的模块执行会更慢些。这就是很明显的封闭式思维和非封闭式思维的区别。
你看MFC的思路，那就是一层套一层的，要把所有的类都实现了，然后继承。它从CWnd以后，把所有的东西都包括进去了，组成一个巨型的类。这个巨型的类连界面到实现统统包括在里面。这时你怎么拆？根本就没有拆的方法，这就是封闭式思维。
如果一个系统、一个程序不能拆的话，则它基本上是做不好的。因为任何一个程序，如果它本身的复杂度越大，它可能出错的几率就越大。比如最简单的，哪个函数越大，则该函数的出错几率就越大。但如果把该函数分成很多......
C++词汇解析集锦 编程开发人员必备(2007-11-21 22:09:00)
摘要： 1. 保留字
C++中，保留字也称关键字，它是预先定义好的标识符。见关键字的解释。
2.关键字
C++中已经被系统定义为特殊含义的一类标识符。C++中的关键字有：
auto
double
int
struct
break
else
long
switch
case
enum
register
typedef
char
extern
return
union
const
float
short
unsigned
continue
for
signed
void
default
goto
sizeof
volatile
do
if
static
while
asm
_cs
_ds
_es
_ss
cdecl
far
huge
interrupt
near
pascal
class
public
private
catch
protected
delete
new
template
friend
this
inline
throw
try
operator
virtual
overload（现不用）
3.标识符
对变量、函数、标号和其它各种用户自定义对象的命名。在C++中，标识符长度没有限制，第一个字符必须是字母或下划线，其后若有字符则必须为字母、数字或下划线。例如count2，_x是正确的标识符形式，而hello!，3th则是错误的。在C++中标识符区分大小写，另外标识符不能和C++中的关键字相同，也不能和函数同名。
4.声明
将一个标识符引入一个作用域，此标识符必须指明类型，如果同时指定了它所代表的实体，则声明也是定义。
5.定义
给所声明的标识符指定所代表的实体。
6.变量
某个作用域范围内的命名对象。
7.常量
常量是不接受程序修改的固定值，可以是任意数据类型。可以用后缀准确的描述......
高手是怎样练成的(3)(2007-11-19 22:36:00)
摘要：
.ui_top{color:#000000;font-size:12px;line-height:18px;}
.ui_top a:link{color:#000000;text-decoration:none;}
.ui_top a:visited{color:#000000;text-decoration:none;}
.ui_top a:hover {color:#000000;text-decoration:underline;}
高手是怎样练成的(3)
因为计算机技术没有任何时候是突变的。它的今年和去年相差不会很大，但是回过头来看三年以前的情况，和现在的距离就很大。所以说，如果你每年都跟着技术进步的话，你的压力就很小，因为你时刻都能掌握最新的技术。但是，如果你落下来，别说十年，就是三年，你就赶不上了。
如果你一旦赶不上，就会觉得非常吃力；如果你赶不上，你就会迷失方向；如果你迷失了方向，你就觉得计算机没有味道，越做越没劲。当你还只是有个思路的时候，别人的产品都做出来了，因为你的水平跟别人相差太远，人家早就想到的问题，你现在才开始认识。水平越高，他就看得越远，那么他的思维就越开阔；水平越低，想的问题就越窄。
64位CPU是这个十年和下个十年最重要的技术之一，谁抓住这个机会，谁就能抓住未来赚钱的商机。CPU是英特尔设计的，对这一点他肯定清楚。举例来说，如果从64位的角度来看现在的32位，就像从现在的角度去看DOS。你说DOS很复杂吗？当你在DOS年代的时候，你会觉得DOS很复杂。你说现在的Windows不够复杂吗？Windows太复杂了，但是你到了64位的时候再去看Windows，就如同现在看DOS一样。
整个64位系统的平台和思维方式、思路都比现在更开阔，打个比方说，现在的Windows里面能开n个DOS窗口，每个DOS窗都能运行一个程序。到达64位的时候，操作系统事实上能做到开n个X86，开n个Windows 98，然后再开n个Windows 95都没有问题，系统能做到这一步，甚至你的系统内开n个Windows NT都没有关系。这就是64位和32位的差别。所以，微软的那些“老头”，四、五十岁的那几个做核心的人，现在正在玩这些东西。你......
高手是怎样练成的(2)(2007-11-19 22:34:00)
摘要：高手是怎样练成的(2)
初级程序员和高级程序员的区别
一般对于一个问题，初级程序员和高级程序员考虑这个问题的方法绝对是不同的。比如，在初级程序员阶段时，他会觉得VB也能做出应用来，且看起来也不错。
但到了中级程序员时，他可能就不会选择VB了，可能会用MFC，这时，也能做出效果不错的程序。
到高级程序员时，他绝对不是首先选择以上工具，VB也好，VC也好，这些都不是他考虑的问题。这时考虑的绝对是什么才是具有最快效率、最稳定性能的解决问题的方法。
软件和别的产品不同。比如，在软件中要达到某个目标，有n种方法，但是在n种方法中，只有一种方法或两种方法是最好的，其他的都很次。所以，要做一个好的系统，是很需要耐心的。如果没有耐心，就不会有细活，有细活的东西才是好东西。我觉得做软件是这样，做任何事情也是这样的，一定要投入。
程序员到达最高境界的时候，想的就是“我就是程序，程序就是我”。这时候我要做一个软件，不会有自己主观的思路，而是以机器的思路来考虑问题，也就是说，就是以程序的思考方式来思考程序，而不是以我去设计程序的方式去思考程序。这一点如果不到比较高的层次是不能明白的。
你设计程序不就是你思考问题，然后按自己的思路去做程序吗？
其实不是的。在我设计这个程序的时候，相当于我“钻”入这个程序里面去了。这时候没有我自己的任何思维，我的所有思维都是这个程序，它这步该怎么走，下步该怎么走，它可能会出现什么情况。我动这个部分的时候，别的部分是否要干扰，也许会动一发而牵全身，它们之间是怎么相互影响的？
也只有到达这个境界，你的程序才能真正地写好，绝对不是做个什么可视化。可视化本身就是“我去设计这个程序”，而真正的程序高手是“我就是程序”，这两种方法绝对是不同的。比如，我要用VB去设计一个程序，和我本身就是一个程序的思维方式，是不一样的。别人也许觉得操作系统很深奥，很复杂，其实，如果你到达高手状态，你就是操作系统，你就能做任何程序。
对待软件要有一个全面的分析方法，光说理论是没有用的。如果你没有经过第一、第二、第三、第四这四个阶段，则永远到达不了高境界。因为空中楼阁的理论没有用，而这些必须是一步一步地去做出来。
一个高级程序员应该具备开放性思维，从里到外的所有的知识都能了解。然后，看到世界......
高手是怎样练成的(1)(2007-11-19 22:30:00)
摘要：
高手是怎样练成的(1)
高手成长的六个阶段
程序员怎样才能达到编程的最高境界？最高境界绝对不是你去编两行代码，或者是几分钟能写几行代码，或者是用什么所谓的可视化工具产生最少的代码这些工作，这都不是真正的高手境界。即使是这样的高手，那也都是无知者的自封。
我认为，一个程序员的成长可分为如下六个阶段。
Ø 第一阶段
此阶段主要是能熟练地使用某种语言。这就相当于练武中的套路和架式这些表面的东西。
Ø 第二阶段
此阶段能精通基于某种平台的接口（例如我们现在常用的Win 32的API函数）以及所对应语言的自身的库函数。到达这个阶段后，也就相当于可以进行真实散打对练了，可以真正地在实践中做些应用。
Ø 第三阶段
此阶段能深入地了解某个平台系统的底层，已经具有了初级的内功的能力，也就是“手中有剑，心中无剑”。
Ø 第四阶级
此阶段能直接在平台上进行比较深层次的开发。基本上，能达到这个层次就可以说是进入了高层次。这时进入了高级内功的修炼。比如能进行VxD或操作系统的内核的修改。
这时已经不再有语言的束缚，语言只是一种工具，即使要用自己不会的语言进行开发，也只是简单地熟悉一下，就手到擒来，完全不像是第一阶段的时候学习语言的那种情况。一般来说，从第三阶段过渡到第四阶段是比较困难的。为什么会难呢？这就是因为很多人的思想转变不过来。
Ø 第五阶级
此阶段就已经不再局限于简单的技术上的问题了，而是能从全局上把握和设计一个比较大的系统体系结构，从内核到外层界面。可以说是“手中无剑，心中有剑”。到了这个阶段......
[转] 何种代码布局风格为佳？(2007-11-17 18:33:00)
摘要：
Q: 何种代码布局风格为佳？
A: 哦，这是个人品味问题了。人们常常很重视代码布局之风格，但或许风格的一致性要比选择何种风格更重要。如果非要我为我的个人偏好建立“逻辑证明”，和别人一样，我会头大的 :O)
我个人喜欢使用“K&R”风格，如果算上那些C语言中不存在的构造之使用惯例，那么人们有时也称之为“Stroustrup”风格。例如： class C : public B {
public:
// ...
};
void f(int* p, int max)
{
if (p) {
// ...
}
for (int i = 0; i < max; ++i) {
// ...
}
}
这种风格比较节省“垂直空间”——我喜欢让尽量多的内容可以显示在一屏上 :O) 而函数定义开始的花括号之所以如此放置，是因为这样一来就和类定义区分开来，我就可以一眼看出：噢，这是函数！
正确的缩进非常重要。
一些设计问题，比如使用抽象类来表示重要的接口、使用模板来表示灵活而可扩展的类型安全抽象、正确使用“异常”来表示错误，远远要比代码风格重要。
[译注：《The Practice of Programming》中有一章对“代码风格”问题作了详细的阐述。]
原文地址：http://www.research.att.com/~bs/bs_faq2.html#layout-style......
[转] 我能防止别人从我的类继承吗？(2007-11-17 18:32:00)
摘要：
Q: 我能防止别人从我的类继承吗？
A: 可以的，但何必呢？好吧，也许有两个理由：
出于效率考虑——不希望我的函数调用是虚的
出于安全考虑——确保我的类不被用作基类（这样我拷贝对象时就不用担心对象被切割(slicing)了）[译注：“对象切割”指，将派生类对象赋给基类变量时，根据C++的类型转换机制，只有包括在派生类中的基类部分被拷贝，其余部分被“切割”掉了。]
根据我的经验，“效率考虑”常常纯属多余。在C++中，虚函数调用如此之快，和普通函数调用并没有太多的区别。请注意，只有通过指针或者引用调用时才会启用虚拟机制；如果你指名道姓地调用一个对象，C++编译器会自动优化，去除任何的额外开销。
如果为了和“虚函数调用”说byebye，那么确实有给类继承体系“封顶”的需要。在设计前，不访先问问自己，这些函数为何要被设计成虚的。我确实见过这样的例子：性能要求苛刻的函数被设计成虚的，仅仅因为“我们习惯这样做”！
好了，无论如何，说了那么多，毕竟你只是想知道，为了某种合理的理由，你能不能防止别人继承你的类。答案是可以的。可惜，这里给出的解决之道不够干净利落。你不得不在在你的“封顶类”中虚拟继承一个无法构造的辅助基类。还是让例子来告诉我们一切吧： class Usable; class Usable_lock {
friend class Usable;
private:
Usable_lock() {}
Usable_lock(const Usable_lock&) {}
};
class Usable : public virtual Usable_lock {
// ...
public:
Usable();
Usable(char*);
// ...
};
Usable a;
class DD : publi......
[转] 我该把const写在类型前面还是后面？(2007-11-17 18:32:00)
摘要：
Q: 我该把const写在类型前面还是后面？
A: 我是喜欢写在前面的。不过这只是个人口味的问题。“const T”和“T const”均是允许的，而且它们是等价的。例如： const int a = 1; // ok
int const b = 2; // also ok
我想，使用第一种写法更合乎语言习惯，比较不容易让人迷惑 :O)
为什么会这样？当我发明“const”（最早是被命名为“readonly”且有一个叫“writeonly”的对应物）时，我让它在前面和后面都行，因为这不会带来二义性。当时的C/C++编译器对修饰符很少有强加的语序规则。
我不记得当时有过什么关于语序的深思熟虑或相关的争论。一些早期的C++使用者（特别是我）当时只是单纯地觉得const int c = 10;要比int const c = 10;好看而已。或许，我是受了这件事实的影响：许多我早年写的例子是用“readonly”修饰的，而readonly int c = 10;确实看上去要比int readonly c = 10;舒服。而最早的使用“const”的C/C++代码是我用全局查找替换功能把readonly换成const而来的。我还记得和几个人讨论过关于语法“变体”问题，包括Dennis Ritchie。不过我不记得当时我们谈的是哪几种语言了。
另外，请注意：如果指针本身不可被修改，那么const应该放在“*”的后面。例如： int *const p1 = q; // constant pointer to int variable
int const* p2 = q; // pointer to constant int
const int* p3 = q; // pointer to constant int原文地址：http://www.research.att.com/~bs/bs_faq2.html#constplacement......
[转] 宏有什么不好吗？(2007-11-17 18:31:00)
摘要：
Q: 宏有什么不好吗？
A: 宏不遵循C++的作用域和类型规则，这会带来许多麻烦。因此，C++提供了能和语言其它部分“合作愉快”的替代机制，比如内联函数、模板、名字空间机制。让我们来看这样的代码： #include "someheader.h"
struct S {
int alpha;
int beta;
};
如果有人(不明智地)写了一个叫“alpha”或者“beta”的宏，那么这段代码无法通过编译，
甚至可能更糟——编译出一些你未曾预料的结果。比方说：如果“someheader.h”包含了
如下定义： #define alpha 'a'
#define beta b[2]那么前面的代码就完全背离本意了。
把宏（而且只有宏）的名称全部用大写字母表示确实有助于缓解问题，但宏是没有语言级保护机制的。例如，在以上例子中alpha和beta在S的作用域中，是S的成员变量，但这对于宏毫无影响。宏的展开是在编译前进行的，展开程序只是把源文件看作字符流而已。这也是C/C++程序设计环境的欠缺之处：程序员和编译器看到的源文件是不同的。
不幸的是，你无法确保其他程序员不犯你所认为的“愚蠢的”错误。比方说，近来有人告诉我，他们遇到一个含“goto”语句的宏。我见到过这样的代码，也听到过这样的论点——有时宏中的“goto”是有用的。例如： #define prefix get_ready(); int ret__
#define Return(i) ret__=i; do_something(); goto exit
#define suffix exit: cleanup(); return ret__
void f()
{
prefix;
// ...
Return(10);
// ...
Return(x++);
//...
suffix;
}
如果你是一个负责维护的程序员，这样的代码被提交到你面前，而宏定义（为了给这个“戏法”增加难度而）被藏到了一个头文件中（这种情况并非罕见），你作何感想？是不是一头雾水？
一个常见而微妙的问题是，函数风格的宏不遵守函数参数调用规则。......