主题：【原创】猛批烂书 程序员面试宝典 上 -- 晨池
先谢谢您的说明，对我的确是一种启发。
细细想来不过也有一些值得商榷的地方。有点剑走偏锋的感觉。与其用虚的析构函数来完成不同的调用，还不如把虚的析构函数的内容直接写成一个个的函数。这样可读性还强点，工作量也应该差不多。
我在用C++的时候用一个原则，该编译器完成的工作让他去做，该自己干的绝不交给编译器。正如您举出的copy constructor例子一样。只要有诸如内存分配或有static的计数器变量等情况，不管3721先把拷贝构造，析构和operator=写了再说，管他用不用。因为编译器可能在你想不到的情况下会决定用他们。这也是改了自己或别人N次的bug的教训。您这种使用构造或析构属于一种implicit的方式，我更喜欢明示的方式。
不过千万请不要误会，我绝不是说您这种方式不好。编程不高深，但有时也会有点“运用之妙存乎于心”的感觉。就好像楼下的讨论什么时候用指针，还真不好回答呢。
做图像处理的一分钟都离不开它。。。
Jpeg用的是DCT，Jpeg2000是Wavelet的说，写FFT是为了在frequency domain做滤镜～默默的昨天把滤镜写错了，我现在用不压缩的灰阶图像（netpbm那个lib），色彩的以后再说
C＋＋中，inline实际上是一个hint，它提示（或建议）编译器此成员函数宜于展开使用，既然是建议，编译器可以不予理睬。原因很多，有可能编译器并不支持函数展开，也有可能用户寻求最短代码而非高效代码。
C＋＋不强制inline函数展开，这样做是有道理的。它增进了代码重用。当调用环境需要较小的代码时，inline就被忽略。而在重视代码效率的环境下，inline 就得到采用。由于使用了inline，函数可用于不同的环境中。
另外，inline所换来的效率提高并不一定增加空间消耗。inline展开的结果之一，就是展开的代码可以在调用环境中予以优化，这样产生的代码反而可能更小。晨池例子的第二部分就说明了这个问题。
原来的代码是 printf("%d",fact(8))
通过展开变成 printf("%d",8*8)
因为 ８＊８ 是常数表达式，继续优化成６４（４０h）
printf("%d", 64)
其机器代码为
push 40h
push "%d"
call printf
当时这样常规的办法，肯定是考虑过的，但是没有采纳。之所以现在还记得，也是因为找了一圈，才这样用的。
优化全开的时候这样处理，您应该对编译器和编译原理很了解吧，我对这方面知道的很少，仅限于C/C++语言编译时候有些特显，我处于兴趣看看汇编给编译成审查样子。
inline，我感觉不用也可以，因为编译器处理的时候，如果有些函数它认为值得，即使我们没有用inline这个关键字，也会扩展开的。。。
至于那个翻译么，嘿嘿，本来就是从烂书里抄出来的，他们那本书里面的翻译很成问题
其实我觉得STL挺好的，在实现上是有一定约束的，而且必然是开源的（目前还没有编译器支持模板不开源发布），所以里面的东西用起来，在满足约束的前提下，还是比较安全的。不过STL封了一层层以后，如果语法有个小错误，那个报错报的啊，真是要人命
STL的vector要求必须用连续的内存空间实现吧，array倒是可以，那个pow用了就踩雷，是什么意思啊？
因为我们做图像视频，很多时候需要用矢量指令，按照cache大小和结构进行优化，所以对体系结构、编译优化都比较感兴趣。有时候需要优化程序，要选择下手的地方，所以得分析编译器的输出，看看瓶颈在哪里。
inline的问题，是各个编译器支持的很不相同。而且如前面有人说的，它仅仅是一个hint。要不要其实不重要。所以现在我写程序基本上不考虑这个。现实而言，Borland的支持很弱，基本上有没有无差别。而且，Borland的编译器要求inline函数必须在头文件中定义，这就导致很多问题。VC支持还可以，且有优化选项，让编译器自动选择小函数做inline。所以差别也不大。其它的用得不多，不是很清楚。
STL的最大问题是它搞得太复杂了，用起来类似于高射炮打蚊子。而且一个非常严重的缺点是，把所有数据结构都搞了一套大致差不多的接口。我用不同的数据结构目的就是用不同的功能，你搞成相同的，我怎么知道你是啥意思啊？所以这玩意对初学者就是满眼的地雷阵。我收上来的作业中，这些错误实在太多太多了。对高手，这玩意又是一个鸡肋，功能虽然强大，但在每次使用的时候，都免不了要写过于复杂的适配代码，而且还没把握写得对不对，更不知道其内部实现算法是否符合预期。还有，不同STL的内部实现差别很大，虽然接口相同，却往往导致不兼容。所有这些问题绞在一起，我非常不建议使用这些东西。再说，实现这些结构都非常容易，每个人都应当有自己的一套库，这样用起来显然是最顺手的，和乐而不为？
比如说2^3有些时候会返回7.9999999999,boss当年ACM world final就在这踩响了地雷
不过,CMATH是C++的(实际上是C的),不是STL的.
中文版《C++ 标准程序库》（侯捷/孟岩译），这本书可以说对是STL规范描述，多翻翻就有感觉了。
比如vector，书中明确说明只支持值语义，而非引用语义。（因此auto_ptr不能在vector类容器中使用：因为它有owner的概念，不支持值语义)。
VC的关键字，应该可以取代inline。（GCC 下为__inline__ __attribute__((always_inline))）。这样应该更符合程序员的口味。（虽然和inline一样不能100%确定把inline展开，比如debug模式，递归函数等。）