Boost库中的lexical_cast函数功能很强大，但存在一个浮点数的精度问题。在阿炯的《走进Boost》中描述如下： #include boost/lexical_cast.hpp #include string #include iostream int main() { using std::string; const double d = 123.1234567; string s = boost::lexical_casestring(d); std::coutsstd::endl; re...

**软件公司软件开发规范 (试行版) 在公司团队协作开发的情况下，编程时应该强调的一个重要方面是程序的易读性，在保证软件的速度等性能指标能满足用户需求的情况下，能让其他程序员容易读懂你的程序。一套鲜明的编程风格,可以让协作者、后继者和自己一目了然，在很短的时间内看清程序的结构，理解设计的思路。大大的提高代码的可读性、可重用性、程序健壮性、可移植性和可维护性。 制定本编程规范的目的是为了提高公司的软件开发效率及所开发的软件的可维护性，提高软件的质量。本规范由程序风格、命名规则、注释规范、程序健壮性、可移植...

cfc::array boost提供了boost::array,但是那只是一维的数组，我实现的这个支持一维，二维和三 维数组，三维以上的没有支持，我想你大概也不大会用到吧？:) 用标准STL容器vector来实现多维数组的话，空间是不连续的,用boost::array实现多维 数组的话,空间是连续的，但是boost的array没有基接口. 我提供的数组类同时支持我实现的这个支持一维，二维和三维数组，提供了所有数组的 基类array_base,一维数组的基类array_1d_base,二维数组的基类arr...

最近看了adrianx的大作《C++实现单件的初探》，真是讲得很好，不过里面有一处疏漏。 现对其Singleton类的设计分析如下： 首先，让我们来对Singleton类进行如下测试： #include iostream using namespace std; // 为了给Singleton类的Instance计数 template typename T class Counter { public: Counter() { ++count; } ~Counter() { --count; } Cou...

《Object Unencapsulated: Eiffel, Java and C++》的作者Ian Joyner说，Object-Oriented应该正名为Type-Oriented（面向类型）[1][5]；侯捷先生在文章中说，STL 其实是在泛型思维模式之下建立起一个系统化的、条理分明的「软体组件分类学」。噢，什么叫分类学？还是类型。[3]看来“类型”这个概念值得我们一说再说。 在面向对象设计（OOD）中，“归类”是重要步骤，一个精心设计的类层次结构是则是OOD的重要成果。类的层次和界面定义得好，...

1. 传指针时，我们可以通过指针来修改它在外部所指向的内容。但如果要修改外部指针所指向的对象是不可能的。例如传递外部指针到函数内来分配空间，必须传递指针的指针或指针的引用。 2. char carry[10] = {0}; 编译器会将其后所有的东西都置0； 3. 函数返回值为const时，返回的东西付给一个类型相同的标示后其不能为左值； 4. const int *i; int const *i; int * const i; 前两个功能相同，说明I所指向的内容不变；最后一个说明指针指向的地址不变，但内...

条款50: 提高对C++的认识 C++中有很多 "东西"：C，重载，面向对象，模板，例外，名字空间。这么多东西，有时让人感到不知所措。怎么弄懂所有这些东西呢？ C++之所以发展到现在这个样子，在于它有自己的设计目标。理解了这些设计目标，就不难弄懂所有这些东西了。C++最首要的目标在于： · 和C的兼容性。很多很多C还存在，很多很多C程序员还存在。C++利用了这一基础，并建立在 ---- 我是指 "平衡在" ---- 这一基础之上。 · 效率。作为C++的设计者和第一个实现者，Bjarne Stroust...

条款49: 熟悉标准库 C++标准库很大。非常大。难以置信的大。怎么个大法？这么说吧：在C++标准中，关于标准库的规格说明占了密密麻麻300多页，这还不包括标准C库，后者只是 "作为参考"（老实说，原文就是用的这个词）包含在C++库中。 当然，并非总是越大越好，但在现在的情况下，确实越大越好，因为大的库会包含大量的功能。标准库中的功能越多，开发自己的应用程序时能借助的功能就越多。C++库并非提供了一切（很明显的是，没有提供并发和图形用户接口的支持），但确实提供了很多。几乎任何事你都可以求助于它。 在归纳...

条款48: 重视编译器警告 很多程序员日常总是不理睬编译器警告。毕竟，如果问题很严重，就会是个错误，不是吗？这种想法在其它语言中相对来说没什么害处，但在C++中，可以肯定的一点是，编译器的设计者肯定比你更清楚到底发生了什么。例如，大家可能都犯过这个错误： class B { public: virtual void f() const; }; class D: public B { public: virtual void f(); }; 本来是想用D::f重新定义虚函数B::f，但有个错误：在B中，f...

条款47: 确保非局部静态对象在使用前被初始化 大家都是成年人了，所以用不着我来告诉你们：使用未被初始化的对象无异于蛮干。事实上，关于这个问题的整个想法会让你觉得可笑；构造函数可以确保对象在创建时被初始化，难道不是这样吗？ 唔，是，也不是。在某个特定的被编译单元（即，源文件）中，可能一切都不成问题；但如果在某个被编译单元中，一个对象的初始化要依赖于另一个被编译单元中的另一个对象的值，并且这第二个对象本身也需要初始化，事情就会变得更复杂。 例如，假设你已经写了这样一个程序库，它提供一个文件系统的抽象，其中...

条款46: 宁可编译和链接时出错，也不要运行时出错 除了极少数情况下会使C++抛出异常（例如，内存耗尽 ---- 见条款7）外，运行时错误的概念和C++没什么关系，就象在C中一样。没有下溢，上溢，除零检查；没有数组越界检查，等等。一旦程序通过了编译和链接，你就得靠自己了 ---- 一切后果自负。这很象跳伞运动，一些人从中找到了刺激，另一些人则吓得摔成了残废。这一思想背后的动机当然在于效率：没有运行时检查，程序会更小更快。 处理这类事情有另一个不同的方法。一些语言如Smalltalk和LISP通常在编译链...

杂项 进行高效的C++程序设计有很多准则，其中有一些很难归类。本章就是专门为这些准则而安排的。不要因此而小看了它们的重要性。要想写出高效的软件，就必须知道：编译器在背后为你（给你?）做了些什么，怎样保证非局部的静态对象在被使用前已经被初始化，能从标准库得到些什么，从何处着手深入理解语言底层的设计思想。本书最后的这个章节，我将详细说明这些问题，甚至更多其它问题。 条款45: 弄清C++在幕后为你所写、所调用的函数 一个空类什么时候不是空类？ ---- 当C++编译器通过它的时候。如果你没有声明下列函数，体...