2010年11月15日
#
摘要: 原子操作和 volatile 关键字
全局对象初始化时的线程安全性和相互依赖性问题
局部静态对象初始化时的线程安全性问题
阅读全文
2010年11月8日
#
摘要: 服务器用的脚本是Python，但是对脚本中的错误异常信息提示总是不好。有的打印不出来，有时打印的是错误的。我对此早就深恶痛绝！前几天一个由于脚本中import来的脚步语法有错，导致总是加载不成功，服务器运行不起来的问题浪费了我一上午的时间，牺牲了无数脑细胞，终于忍受不了了。用了两天多时间，终于彻底解决了这个问题，定义函数如下，如果Python脚本加载或者调用出错，调用下面这个函数就可以将错误信息记录在字符串中。
阅读全文
2010年11月1日
#
模板元编程（Template Metaprogramming）更准确的含义应该是“编‘可以编程序的’程序”，而模板元程序（Template Metaprogram）则是“‘可以编程序的’程序”。也就是说，我们给出代码的产生规则，编译器在编译期解释这些规则并生成新代码来实现我们预期的功能。
模板元编程由于把运算由执行时提前到了编译时，所以其一个特点是运行时很快，效率很高！不过这是以编译耗时为代价的。这个作用主要体现在复杂的数值运算时。另外一个特点是能解决普通的C++程序无法解决的问题，这时才是模板元编程大显身手的时候。这个作用体现在类型识别和处理时。
因为模板参数都要是编译时常量，而我们的运算需求大部分时候应该都是对变量的运算，所以我认为模板元编程解决数值运算问题可能意义不大，可能主要是用来封装在泛型库底层来完成复杂的类型处理功能。
还有我觉得最大的问题是，模板元编程就如同正则表达式等一些技术一样，作用很强大，但是用到的地方似乎很少，以至于学习和练习都找不到施展空间~O(∩_∩)O~
2010年10月25日
#
设计类的成员函数的架构，在继承体系中，除了直接定义virtual函数外，还应当考虑以下几种方案：
1。由Non-Virtual Interface手法实现Template Method模式
NVI手法：令客户通过publicnon-virtual成员函数间接调用private vritual函数。这就是Template Method设计模式的一个独特表现形式。这个non-virtual函数称为virtual函数的外覆器（wrapper）。
2。有Function Pointers实现Strategy模式
类中存储的是函数指针
3。有tr1::function完成Strategy模式
类中存储的是函数对象，相比前者，好处是允许客户在计算是使用任何与函数对象相兼容的可调用物。
4。古典的Strategy模式
类存储的是策略类对象的指针。
各自优缺点：
直接的virtual和NVI手法，面向对象组织结构很明确，但是扩展性不强。
Strategy模式：扩展性强，灵活。但是将机能从成员函数移到class外部函数的缺点是，非成员函数无法访问class的non-public成员。
2010年10月9日
#
---------摘自《C++ Primer中文版》
模板是C++语言与众不同的特性，是标准库的基础。模板是独立于类型的蓝图，编译器可以用它产生多种特定类型的实例。我们只需编写一次模板，编译器将为使用模板的不同类型实例化模板。既可以编写函数模板又可以编写类模板。
函数模板是建立算法库的基础，类模板是建立标准库容器和迭代器类型的基础。
非类型模板实参必须是编译时常量表达式。
编译模板需要编程环境的支持。语言为实例化模板定义了两个主要策略：包含模型和分别编译模型。这些模型规定了模板定义应该放在头文件还是源文件中，就此而言，它们影响着构建系统的方式。现在，所有编译器实现了包含模型，只有一些编译器实现了分别编译模型。
显式模板实参使我们能够固定一个或多个模板形参的类型或值。显式实参使我们能够设计无需从对应实参推断模板类型的函数，也使我们能够对实参进行转换。
模板特化是一种特化的定义，它定义了模板的不同版本，讲一个或多个形参绑定到特定类型或特定值。对于默认模板定义不适用的类型，特化非常有用。
2010年9月25日
#
摘要: Unix哲学之一言以蔽之——KISS。Keep It Simple,Stupid!
要良好地运用Unix哲学，你需要具备（或者找回）这种态度。你需要用心。你需要去游戏。你需要乐于探索。
阅读全文