随笔档案

@xcj
多谢回复。

vim、emacs的强大之处，我并没有否认，我现在还在用vim编辑很多东西，但是我已经过了狂热的那个时候了，我不会用vim来编辑C/C++代码，毕竟有比vim和emacs更好的IDE，我自然是优先使用它们。我也同样使用emacs + paredit来写scheme代码，但是我不会用emacs编辑其他文件，因为有vim和更好用的IDE，我现在是哪个编辑适合编辑哪种类型的文件，我就使用哪个编辑器。至于你说的混淆IDE和编辑器，我不知道我文中哪里有把他们混淆，我说的很多人说这些编辑器可以通过插件完成各种功能，都是停留在理论里，实际效果并不好，而很多人用个编辑器都能产生优越感。

对于MBA，我只说过死了两次机，但是我并没有说它不好，相反它是我用过的笔记本里最好的，我最近两年的时间基本都在使用MBA。我所说的是那些用了个MBA和MBP就产生优越感的人。

对于C/C++的问题，对于我这个从C语言入门程序设计的人来说，我还是有自信自己能写出基本合格的C程序的。C++程序员不合格的多，但是我还是见过几个真人（身边的）能写出合格的C++程序，而对于写出合格C程序的程序员，在我身边我目前还没见过（我所在的公司的部门一直以来都写C为主），当然你可以说我的层次比较低，我确实没见过活的写C程序牛逼的程序员。

另外技术的优越感一说，这就是跟我公司环境有关了，这个我只能说你对我的评价太过武断了。

对于你说的最后一句话，这一直都是我的写程序的基本原则。而我说的那些带有优越感的人，才应该学习你这句话。

@陈梓瀚(vczh)
哈哈，早知道陈祖写过正则引擎的系列文章，一直没看，是想在我自己思考之后如果遇到问题的时候再看，啊哈哈。

膜拜空明巨巨！

@zenk

OP_VARARG这条指令就是访问...参数的，可以看到用
int n = cast_int(base - ci->func) - cl->p->numparams - 1;
来计算可变参数变参的个数（cl->p->numparams是这个函数的固定参数的个数），接下来在判断B参数是否为0，如果为0，那就有多少个变参就复制多少个，不然就复制B - 1个变参。在lua中如下代码会生成OP_VARARG指令：
function f(...)
print(...)
end

至于arg变量，在lua 5.2中已经不会自动打包可变参数...为一个arg变量，在lua 5.2中要使用arg变量可以这样写：
function f(...)
local arg = table.pack(...)
end

@zenk
我对这段描述不够清楚，现在已经补上了。

复制的只是固定的那些参数，"..."所代表的变参并没有复制，保留在base指针前面，这样可以保证后续指令访问固定的那些参数和非可变参数函数是一致。

同感呐。

@LOGOS
笔记本你就没办法用手掌左侧了。

匈牙利命名法的一个及其明显的弊端，比如：
开始定义了一个 int nSize;使用了一段时间后，被后面维护代码的人因为某种需求改成了DWORD（或者其它类型），那是不是这个变量也要跟着改成dwSize才能符合匈牙利命名法，但是如果这个变量被很多地方使用，改起来岂不是很麻烦。虽然可以通过VA来rename，但是在团队开发中，团队成员不一定会去把变量名同步修改。
当然这只是个例子。
另一方面我非常赞同空明流转兄，我觉得变量类型编译时期就确定了，没有必要这么去在变量名里面暴露类型。而对于动态语言的话，那类型更加不确定，随着运行的过程，变量可以是任意类型，所以我觉得变量是要表达你所要代表的意思而不是类型。像上面那个例子的变量名为size就行，表达出它的作用就行，当然可能还会具体些，命名为xxx_size。
在C++模板中，模板中的代码类型更加不确定了，自然不能把类型写到变量名中。

1、四格缩进，整体简洁统一，函数不要太长，一般不超过30行。
2、只要是非匈牙利命名法觉得都可以（最讨厌匈牙利命名法，看了《观止》之后发现卡特勒也很讨厌它，我就更加坚定了），比较喜欢google的命名方式。
3、逻辑简洁，函数和类单一职责，RAII，个人比较倾向使用异常，异常能够让代码更整洁的处理错误。当然公司的话，看项目是怎么定的了。

特别希望其他人提交到库里面的代码没有注释掉的代码，最讨厌看到注释掉的代码。函数不要太长，类不要太大，一切都是为了单一职责。
被强加的规则，好的接受，不喜欢的也得接受，因为自己不是老大。

Windows上开发的程序个人倾向静态链接，一是用的都是最新的VS（目前用VS2010），为了让程序在没有装CRT机器上运行；二是个人开发的程序不大，静态链接体积也大不了多少。
公司开发一般都是动态链接。

“加上volatile关键字后在gcc上就能得到正常的结果了”什么是你想要的正常结果？既然标准既没有规定求值顺序，那你的想要的"正常结果"即使在你使用了某种特殊的方法后得到了，那换了一个编译器之后也不一定就是你想要的。标准没有规定求值顺序，决定权自然是有各个编译器掌握，而gcc自然有权利决定加volatile和不加volatile的结果是否相同。

这个跟volatile没关系的，int m = (++z) + (++z) + (++z);这个东西的求值顺序标准没有规定，不同编译器的实现是不同的。

标准没有规定先对哪个求值，完全由编译器决定，而对于这种标准未定义的东西，没必要去浪费时间，你只需知道求值顺序不确定就行，在实际编码中就不应该出现这样的代码。
PS:其实你可以BS下出这种题目的人。

@lv
恩，基于libtorrent的软件很多，Deluge就是其中之一。

额，还是膜拜下。

继续膜拜大神！

保持队形，膜拜大神啊！

@陈梓瀚(vczh)
不定参数模板是可以实现Tuple的，可以看看gcc 4.5的Tuple的实现，它就是用的不定参数模板来做的。

@cexer
@陈梓瀚(vczh)
两位都说的不错，自身的提高都是通过自我否定之后，重新定一个新的目标来达到的。

Loki::ScopeGuard实际上是一个通用的RAII，它是通过在ScopeGuardImplBase的所有派生类的析构函数里面SafeExecute(*this)来做到RAII，而在SafeExecute做资源释放操作是通过调用派生类的fun_，如果不try...catch，那么fun_执行如果发生异常的话，那异常就逃离了析构函数。在C++中析构函数是不应该有异常产生的，详见《Effective C++》。

单元测试最好是在项目初期就使用，项目已经到后期的才做单元测试性价比不高，尤其是各个模块间的耦合很大时很难做单元测试。项目开始就用单元测试可以帮助降低模块的耦合。

@expter
可以啊，这个调试器主要就是用来调试作为C++扩展的Lua。

@megax
像ctags这种仅仅是提取token来作提示只能应付简单C语言程序，复杂一点的C++程序，多点template，多点typedef，ctags分析的那些东西就费掉了，个人觉得要做好智能提示必须通过语法分析来做。所以有些vimer和emacser才会不满于ctags和etags这些东西，CEDET这种东西才会出现，不过比起VA来说还是差远了。

google常量折叠

@陈梓瀚(vczh)
C++的一个哲学就是让类库尽可能的提供功能，为了达到这个目标，不同的语法就必需尽可能正交，而且功能强大到到处都可以插入callback，从而写出高质量而且语法优美的类库了。所以正确的使用方法应该是大规模使用stl和boost，而不是直接使用C++去构造所有东西。
====================================================
赞同，这段话让我想起了《C++ 沉思录》中说的：语言设计就是库设计，库设计就是语言设计。