C++ 对象是怎么死的？关于标准输入输出流（cout,cerr,clog,etc）的进一步探讨

　　昨天的帖子《C++ 对象是怎么死的？进程篇》，在谈到全局对象的析构顺序史，举了一个“在析构函数中使用 cout”的例子（代码详见原文）。当时的本意是想说明：全局对象的析构顺序是不确定的，最好不要在程序逻辑中依赖这个顺序（免得出现移植问题）。
　　没成想该帖子引来热烈的评论（俺有点受宠若惊了），关注的焦点主要集中在：“cout 是否会最后析构”。有些网友质疑我所提到的有关 VC6 的行为；有网友引用了《TCPPPL》上的相关章节（21.5.2）来说明“cout 会最先构造、最后析构”。既然大伙儿对标准流类库的构造和析构挺有兴趣，咱们今天就针对这个话题补充说明一下。

C++ 对象是怎么死的？为什么要写这个系列？

　　要说 C++ 对象是怎么死的，得先从 C++ 的析构函数说起。这玩意儿是我本人很喜欢的一个语言特性（可惜有好几个语言没有类似的玩意儿，具体就不点名了，免得引发口水战）。我们可以利用 C++ 的构造和析构函数，来实现 Guard 模式，写出比较清晰、简练和异常安全的代码。由于 Guard 模式在 C++ 程序中运用挺多，所以保证【所有对象被析构】就是一个很重要很严肃的问题。

C++ 对象是怎么死的？进程篇

　　我承认这个帖子的名称有标题党的嫌疑，但是暂时想不出更好的名称了，只好先这样了 :-(
　　由于前天的帖子聊了架构设计的多进程问题，所以今天想起来要聊一下与“C++进程终止”相关的那些事。与前几个 C++ 帖子的风格类似，今天聊的内容，尽量局限于标准 C++ 范畴，尽量不涉及特定的操作系统平台。

如何成为优秀开发人员[7]：正确地做事（善用自动化）

　　上一个帖子聊了“善用工具”的话题，讲的都是如何有效利用工具来提高效率，今天说一下如何利用“自动化”来提高效率。

架构设计：进程还是线程？是一个问题！

　　就像莎士比亚的“To be, or not to be, that is the question”始终困扰着哈姆雷特，对于“进程还是线程？”这个问题，也经常困扰着那些进行软件架构设计的家伙。所以今天打算聊一下我对这个问题的体会。假如你还搞不清楚线程和进程的区别，请先找本操作系统原理的书好好拜读一下，再回来看帖。
由于这个问题很容易引发口水战，事先声明如下：多进程和多线程，无法一概而论地说谁比谁好。因此本帖主要描述特定场景（与我所负责的产品相关）下，进程和线程的权衡经验，仅供大伙儿参考。

软件工程进阶之每日构建[3]：流程

　　在上一个帖子已经介绍了几方面的准备工作，今天来说一下具体流程。对于流程的每一个环节，俺会强调一下容易出问题的地方。

学习技术的三部曲：WHAT、HOW、WHY

　　最近几天有些网友在邮件里面问我关于学习的问题。有好几个人觉得工作了几年，也学会了不少的类库、框架、甚至语言，但是感觉自己的能力没有太大的提高。因此今天来说一下我个人对这方面的体会，希望对大伙儿（尤其是新手）有帮助。
　　先声明一下，本帖子讨论的三部曲是指你已经选定了某个技术方向之后，该如何学习；至于如何选定技术方向，则属于另一个话题，不在今天的讨论之列。
　　我把学习归类为三个步骤：What、How、Why。经过我对周围同事和朋友的观察，大部分感觉自己技术没有提高的人，都仅仅停留在 WHAT 阶段。下面我把这三个步骤解释一下。

软件工程进阶之每日构建[2]：准备工作

　　上一个帖子务虚了一下每日构建的几个主要好处。今天开始来说点实在的：也就是每日构建具体要如何开始搞，要做哪些准备工作（如果你所在的团队已经在用每日构建，你可以跳过这个帖子）。

软件工程进阶之每日构建[1]：好处和优点

　　上一个帖子《软件工程进阶之每日构建[0]：概述》提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，俺先来说一些陈年往事。

软件工程进阶之每日构建[0]：概述

　　在昨天的帖子《正确地做事(善用工具)》里提到了代码提交频度的问题。当时俺特别强调了【要保证提交的代码能编译通过】，理由是“对于每日构建很重要”。估计列位看官中，不太熟悉【每日构建】的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天咱们就来说一下“每日构建”这个话题。假如你平时已经很善于运用“每日构建”这一有效的手段，可以直接略过本系列，去看其它帖子。

如何成为优秀开发人员[6]：正确地做事（善用工具）

　　俗话说“工欲善其事，必先利其器”，今天我们来说说和开发工具有关的话题。由于开发过程中会用到的工具多种多样，根据“二八原理”，我只挑选和开发最密切相关的少数几种工具来聊一聊。

如何成为优秀开发人员[5]：正确地做事（概述）

　　从上一个帖子“做正确的事”写完到现在已经过去2周了，有网友已经等不及，在评论中催我了。在此向等待本系列的网友致歉。
　　和“做正确的事”相对应，“正确地做事”主要讨论的是有关工作【效率】和工作【质量】的关系（也就是如何“多、快、好、省”地完成工作）。由于"正确地做事"这个话题比较大，涉及到几个不同方面的【方法论】，考虑了很久，感觉一个帖子难以全部写完（俺不喜欢写长篇大论的帖子）。最后决定搞个【子系列】，针对每个方面写一个帖子。

如何选择开源项目？

　　近几年开源项目越发普及，很多商业软件都逐渐引入开源项目。由于俺负责的产品线采用了不少开源项目（主要是 C++、Java、Python），这几年就经常会碰到开源项目选型的问题（从几个具有类似功能的开源软件项目中进行抉择）。今天我就大概聊一下自己的几点看法，供大伙儿参考。

Java 新手的通病[4]：异常处理使用不当

　　上一个帖子讨论了“编程习惯的问题”，今天来聊聊关于异常处理的话题。

无处不在的二八原理[1]：在软件开发中的应用

　　上次聊了《什么是二八原理》，接下来得说说如何运用了。由于本博客主要谈 IT 技术，显然要先来说说和程序员有关的那些事。为了不至于太抽象，咱们以“开发文本编辑器”为例（这玩意大伙儿都熟悉，省得费口水解释），来说说不同职责的开发人员在开发过程中该如何具体运用二八原理。

无处不在的二八原理[0]：什么是二八原理

　　估计看俺博客的人里面，应该有很多人听说过二八原理（如果你之前从来没听说过，那你的知识面有太窄的嫌疑）。但是知道二八原理的人有很多却不会（或者不善于）运用。直接的后果就是你在各种事情上付出了很多时间与精力，但是回报却很少。鉴于该原理非常非常的实用，俺打算专门写一个系列来聊聊和它相关的话题。

C++ 的可移植性和跨平台开发[5]：操作系统

　　上一个帖子提到了“硬件体系”相关的话题，今天来说说和操作系统相关的话题。

三种主流 RIA 技术之争，你该如何选型？

　　前几天听说 Adobe 发布了用于 Flash Player 的 RTMP（实时消息协议），在“这里”。乍一看，好像是一个不错的东东。号称有如下优点：支持高性能地把数据（主要是音频、视频）PUSH 给 Flash Player；支持 over HTTP 和 HTTPS。再联想到最近1-2年，微软在 Silverlight（详细介绍看“这里”）上也是频频出击。而 Sun 也不甘寂寞，搞出了一个 JavaFX（2个月前刚发布，详细介绍见“这里”）。看来RIA领域的竞争有白热化的趋势。干脆今天就来八卦一下这三个技术。

Java 新手的通病[3]：缺少良好的编程习惯

　　上次聊了“缺乏面向对象基本功”，今天来说说编程习惯的问题。今天说的这些坏习惯大部分都是跨语言的（C++、Python 新手也有），而且大部分都需要靠平时不断地努力才能慢慢改掉。

学会透过现象看本质，即使现象有时候挺诡异

　　最近看到一个【汽车对冰淇淋过敏】的小故事（原文在此），转述如下：

　　某汽车公司收到投诉信，用户抱怨了一个匪夷所思的经历：
　　他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋，则回家时汽车就无法发动；如果买其它口味的冰淇淋，则汽车可以正常发动。天天如此。该用户怀疑这款汽车是否对香草冰淇淋过敏。

从 Google 搜索的严重 bug 想开去

　　昨天晚上用 Google 查资料，看到所有的搜索结果都注明是恶意站点。第一反应以为自己眼花了；然后开始怀疑我的浏览器出问题，换了几个浏览器都是老样子；后来又想，会不会是我的 ISP 在搞鬼。等了十多分钟没解决，只好换百度查资料...