而 GraphicsEngine.是：
“一个简单的数字图像处理引擎，提供各种基本图像处理算法、连通域分析和内存管理。API为两层结构，并在不断完善中。来自北京航空航天大学机械工程及自动化学院。张以成”
来自"褪墨"的最新文章，
是否真有幸福并非取决于天性，而是取决于人的习惯。褪墨上曾分享过哈佛大学企业管理硕士，杨百翰大学博士史蒂芬・柯维（Stephen R.Covey）的《高效能人士的七个习惯》上几篇文章：《学会积极主动》和《要是第一》，而本文将列举七个低效能人士的坏习惯。欢迎大家参加褪墨号召的《一个月培养一个好习惯》活动！
也许你曾经听过伍迪·艾伦所说的这句话："百分之八十的成功来自于出席。"更多的出席——这是在生活中保证更多成功要做的最重要也是最简单的事情之一。例如，如果想要改善自己的健康状况，最有效的事情就是每天按时出现在健身房里，无论是天气是多么不好、你是多么不想出门、你是多么的繁忙，只要你能坚持在积极性不高的时候能出席健身房，你就会开始改善健康，而不是每天躺在沙发上幻想自己的身体忽然变得更健康了。如果你想提高写作水平或绘画水平，你就要经常练习。如果你想交更多的朋友，就需要出席更多的活动。学会出席，积极主动的参与，这将使你的生活受益匪浅。
我最喜欢的三种摆脱拖拉情况的方法，列举如下：
拓展阅读：《防止拖延的积极步骤》
除了拖拖拉拉以外，另外一个容易陷入的不良习惯就是深陷无关紧要的事情之中。为了提高效率你也许需要某种时间管理方法。比如这套极为简单的时间管理方法，使用80/20法则。80/20法则，也就是我们通常所熟悉的帕累托法则，认为80%的收获源自20%的努力。所以为求高效，你应该将大部分精力集中在那些极少数重要的事情上。你只需按优先顺序写下这一天你需要做的三件最重要的事情，然后从头做起。即使你只能完成其中的一件事，你仍然完成了今天最重要的事情。也许你也会偏爱其他诸如GTD等方法，不过无论你如何组织工作，最关键的还是寻找那些最重要的工作，这样你就不必花费几天，几个星期甚至几个月的时间去忙于那些并不是很重要的事情。如果这些事情无关紧要，那么即使你快速的完成它们也是没有多大用处的。
拓展阅读：《放置大石头的艺术：让你的效率翻倍》
因为多虑而使我们很少采取行动，陷于无穷的分析之中只会使虚度光阴。行动之前加以思考是没有错的，做一些调查研究，制定一个计划，探究可能存在的积极以及不利因素。但是强制性地反复思考就会成为另外一种浪费时间的做法了。在尝试之前你没有必要去从每一个角度检查每一件事情。而且你也不可以等到一个最完美的时间再去做事，因为这样的时间从来不会出现。如果你继续这样思考就只会使自己陷的越来越深，从而使采取行动变得越来越难。相反，虽然思考在一定程度上对你有所帮助，但你现在需要做的就只是停止思考，然后去做那些你应该做的事情。
当你凡事都从消极方面考虑时，你的积极性就会被大大打击。你会发现到处都是问题和错误，而这些问题和错误可能是本不存在的，所以不要抓住细节不放。当你从一个消极角度看问题时，每次你都可能找出十个借口来逃避问题，因此你几乎一事无成。你向任何愿意倾听的人诉苦（也许很多人并不想听），抱怨你的工作，生活和领导有多么的差劲。其实，你的生活取决于你如何看待这个世界。对此的一个解决方法就是了解消极方面的限度，认识到你的消极思考并不是这个世界的真实写照。然后不妨尝试一些其他的角度。举例来说，你可以尝试着培养一下凡事从更为积极和乐观的角度思考的习惯，这会对你大有帮助。通过这种方式，你也许就会开始尝试这种积极性的挑战。这并不容易，然而如果你接受了这种挑战，连续7天都只从积极方面思考，ä �就会突然意识到你看问题的角度和想法是如此深刻地影响着你对世界的理解和你所得到的成果。
拓展阅读：《如何打破消极思维模式》
我们很难去承认自己的想法不是最佳选择，因此我们通常过于执着自己的想法，变得闭目塞听，而这会让你很难取得进步。在这种情况下，即使认真思考改变人生的可能性都会变得很难。显然，解决方法之一就是打开心胸，开阔视野，从他人和自己的错误中汲取教训，从书籍等资源中获取知识。与任何事一样，这事说起来容易做起来难。正如前面所说，对此我的建议就是认识到你的知识领域毕竟是有限的，而你做事的方式也会存在不足。那么不妨就尝试一下新事物吧。 而我的另一条建议就是，阅读一下埃克哈特·托利的《新天地》，特别是有关Ego的章节。正如托利所建议的，如果你不再像Ego那样思考，你就会更加容易接受新思想，抛弃那些已经无用的旧思想。另外我想要补充说明的就是：不要迷信书本，也不要盲目追求新的信息，否则你就会成为一个沉迷于自我帮助的人。在行动中运用那些新信息和你学到的事情，然后加以尝试。
信息过剩并不是说你过多的阅读，我所指的是所有输入信息的过剩。如果你让所有的信息都涌进大脑，这当然会导致难于清晰思考，因为刺激源太多了。以下就是这种习惯可能会存在的弊端：
原文：7 Habits of Highly Ineffective People – The Positivity Blog
车牌识别包括预处理、定位、字符分割和字符识别等几部分。在本文中，我们仅讨论预处理的二值化过程。二值化的好坏决定着车牌识别的精度。事实上，要提高车牌识别精度必须要有好的二值化方法。本文提出了一种新的直接基于彩色图像的二值化方法。
车牌识别，一直存在两种思路。一是将彩色图像灰度化，然后二值化等等；二是直接基于彩色图像。
由于直接基于彩色图像的方法大都未取得很好的效果，因此，造成灰度化、二值化成为目前车牌识别的主流。但是，采用灰度化的方法，有个根本的问题就是，灰度化是有损的。灰度化难在阈值选取。尽管没有理论证明，车牌识别的精度很难超过90%，这或许就与阈值的选取有关。
要跳出阈值选取的怪圈，我认为车牌识别就还是应该回到彩色模式上来。其实，彩色图像为什么要灰度化？其依据是彩色图像需要占用大量的处理时间。老师上课的时候是这样在讲，教科书上也是这样在写。
从广泛的意义上讲，彩色图像确实会占用大量的处理时间，但是，针对车牌识别而言，我们可以找到一种非常简单的方法。通过这种方法，彩色图像会被极大地简化，就是说可以简化到无需考虑处理时间的占用问题。
注意，我说的是简化。就是说，我们要通过简化的方法，达到通过灰度化实现二值化同样的目标，即将彩色图像直接简化成二值化图像，简化过程不使用灰度化方法，仅通过空间映射方式。这样做的好处是什么呢？它克服了灰度化的有损性，最大限度地保持了图像的原貌。传统的方法经灰度化后得到的二值化结果，已经完全丧失原有的色彩信息，而新的通过空间映射的方法，同样得到了二值化图像，但是，图像中每个像素的原色彩信息依然保留着。
直接基于彩色图像的二值化简化，其核心思想是通过：黄色 =（红色＋绿色）/ 2 ，依此将红、绿、蓝三原色构成的色彩空间映射到由黄、蓝两种颜色构成的色彩空间；映射后的色彩值有黑色、蓝色、灰色、黄色和白色五种。具体的简化过程如下：
1、建立公式：黄色 =（红色＋绿色）/ 2 ，取值0..255。
2、建立公式：灰度 =（黄色＋蓝色）/ 2 ，取值0..255。
3、将黄色和蓝色都大于187的视同白色。
4、将黄色和蓝色都小于153的视同黑色。
5、去除白色和黑色剩下的中间色中，如果黄色＜0.9×蓝色（意味着颜色偏蓝），则需进一步进行蓝色细分；如果蓝色＜0.9×黄色（意味着颜色偏黄），则需进一步进行黄色细分；否则则需进一步进行灰色细分。
6、蓝色细分：如果黄色＜0.8×蓝色，说明颜色中蓝色成分明显多于黄色成分，视同蓝色；否则，如果灰度＜187，视同蓝色，反之视同灰色。
7、黄色细分：如果蓝色＜0.8×黄色，说明颜色中黄色成分明显多于蓝色成分，视同黄色；否则，如果灰度＞153，视同黄色，反之视同灰色。
8、灰色细分：如果灰度＜153，视同黑色；如果灰度＞187，视同白色，否则视同灰色。
经过空间映射，现在的空间由黑色、蓝色、灰色、黄色和白色五种颜色构成。显然，这个空间仍然可以被看成是彩色空间，它包括中国车牌所需要的各种底色和字符色（红字需要再特殊处理一下），所有色彩信息都没有丢失。注意，这里有灰色，它正好解决了对“脏”车牌的识别。
进一步我们可以将黑色和蓝色统一归并为蓝色，黄色和白色统一归并为黄色。灰色可根据底色视同蓝色或黄色。这样我们就完成了直接基于彩色图像的二值化简化。
上述直接基于彩色图像的二值化简化方法，最关键的是把空间简化了，把RGB三维空间简化成YB二维，然后，继续简化成直线，再继续简化成五个值，最后简化成二值，节省了计算时间。它与其他的彩色模式的差异在哪里呢？其他的彩色模式大都没有降低维数，减少计算量，即尽管采用了彩色模式，但是最后还是要回到灰度化上面去。这是不对的。
实际应用时，参数会略有调整，测试请到 http://www.yulaohui.com/color5_2/ 。
http://blog.csdn.net/phinecos/archive/2009/10/29/4745720.aspx
首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。
最简单的方法当然是借助于专业的检测工具，比较有名如BoundsCheck,功能非常强大，相信做C++开发的人都离不开它。此外就是不使用任何工具，而是自己来实现对内存泄露的监控，分如下两种情况：
一. 在 MFC 中检测内存泄漏
假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。
我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:
DEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。
在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：
在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。
二．检测纯C++的程序内存泄露
我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。
下面一步一步来把程序的内存泄露检测的机制建立起来。
首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。
我们会用到里面很重要的几个函数。其中最重要的是 _CrtDumpMemoryLeaks();自己看MSDN里的帮助吧。使用这个函数，需要包含头文件crtdbg.h
该函数只在Debug版本才有用，当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“Output(输出)”窗口中显示内存泄漏信息.写段代码试验一下吧，如下：
检测内存泄露版本一：
运行后，在Output（输出）窗口，显示了如下的信息：
但是这个只是告诉我们程序有内存泄露，到底在哪泄露了一眼看不出来啊。
看我们的检测内存泄露版本二：
该程序定义了几个宏，通过宏将Debug版本下的new给替换了，新的new记录下了调用new时的文件名和代码行.运行后，可以看到如下的结果：
呵呵，已经和MFC程序的效果一样了，但是等一等。看下如下的代码吧：
运行后可以发现我们删除了指针，但是它仍然报内存泄露。所以可以想象，每调用一次new，程序内部都会将该调用记录下来，类似于有个数组记录，假如delete了，那么就将其从数组中删除，而_CrtDumpMemoryLeaks()就是把这个数组当前的状态打印出来。
所以除了在必要的时候Dump出内存信息外，最重要的就是在程序退出的时候需要掉用一次_CrtDumpMemoryLeaks();
假如程序有不止一个出口，那么我们就需要在多个地方都调用该函数。
更进一步，假如程序在类的析构函数里删除指针，怎么办？例如：
可以看到析构函数在程序退出的时候才调用，明明没有内存泄露，但是这样的写法还是报了。
如何改进呢,看检测内存泄露版本三：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF.
这样，该版本已经达到了MFC一样的效果了,但是我觉得光这样还不够，因为我们只是在Output窗口中输出信息，对开发人员的提醒还不明显，经常会被遗漏，而且很多人就算发现了内存泄露，但是不好修复，不会严重影响到程序外在表现，都不会修复。怎么样能让开发人员主动的修复内存泄露的问题呢？记得曾经和人配合写程序，我的函数参数有要求，不能为空，但是别人老是传空值，没办法了，只好在函数开始验证函数参数，给他assert住，这样程序运行时老是不停的弹出assert，调试程序那个烦压，最后其他程序员烦了，就把这个问题给改好了，输入参数就正确了。所以我觉得咱要让程序员主动去做一件事，首先要让他觉得做这个事是能减轻自己负担，让自己工作轻松的。呵呵，那咱们也这样，当程序退出时，检测到内存泄露就让程序提示出来。
看检测内存泄露版本四：
该版本会在程序退出时检查内存泄露，假如存在就会弹出提示对话框.
atexit(Exit);设置了在程序退出时执行Exit()函数。Exit()函数中,假如存在内存泄露，_CrtDumpMemoryLeaks()会返回非0值，就会被assert住了。
到这个版本已经达到可以使用的程度了。但是我们还可以做些改进，因为真要准确的检测到代码中所有的内存泄露，需要把代码中的#define……拷贝到所有使用new的文件中。不可能每个文件都拷贝这么多代码，所以我们可以将他提取出来，放在一个文件中，比如我是放在KDetectMemoryLeak.h中，该文件内容如下：
然后将KDetectMemoryLeak.h包含在项目的通用文件中，例如用VS建的项目就将其包含在stdafx.h中。或者我自己建的一个Common.h文件中，该文件包含一些通用的，基本所有文件都会用到的代码。
This document answers some common questions concerning catch(...) and exceptions in general as implemented by Visual C++. It's structured mainly as a conversation, in which one question and answer leads to the next, so you'll get the most out of it if you read it as a whole. To give you a quick idea of what I'm going to talk about, the questions are:
| Q1 | I wrote the following, and I don't understand why catch(...) doesn't catch the Win32 structured exception in a release build, or in general, when compiling with optimizations (e.g. /O1 or /O2). |
| Q2 | I also wrote the code above, and I don't understand why the Win32 structured exception (SE) is caught in a debug build or when I compile with /EHa. Also, I sometimes find that catch(...) catches SEs even in release builds when I use /GX. Isn't catch(...) supposed to catch only C++ exceptions? |
| Q3 | So what are the consequences of catching Win32 Structured Exceptions (SEs) in catch(...) ? |
| Q4 | What about _set_se_translator? |
| Q5 | How do I deal with all this? |
| Q6 | How do I safely use _com_error, std::exception, and other non-MFC exception classes in MFC programs? |
This document applies to Visual C++ 5 through Visual C++ .NET 2003 and beyond. The upcoming Visual C++ 2005 release, known also as "Whidbey", corrects one of the problems discussed below, and this partly affects questions Q1, Q2, and Q5, which are updated accordingly. The remaining questions and answers apply in full to Visual C++ 5 and later.
Q1. I wrote the following, and I don't understand why catch(...) doesn't catch the Win32 structured exception in a release build, or in general, when compiling with optimizations (e.g. /O1 or /O2).
#include <stdio.h>
int main()
{
try
{
int* p = 0;
*p = 0; // Cause access violation
}
catch (...)
{
puts("Caught access violation");
}
return 0;
}
A. In Visual C++5 through Visual C++ .NET 2003, you're compiling with /GX or /EHs, which enables the compiler's synchronous exception model. This model is defined to catch only exceptions resulting from a C++ throw statement, and there is no such statement in the above. If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception. This is a great optimization! It's especially appreciated when writing template code. Unfortunately, there is a bug that causes catch(...) to catch Win32 structured exceptions in some scenarios, which leads to the next question.
Q2. I also wrote the code above, and I don't understand why the Win32 structured exception (SE) is caught in a debug build or when I compile with /EHa. Also, I sometimes find that catch(...) catches SEs even in release builds when I use /GX. Isn't catch(...) supposed to catch only C++ exceptions?
A. According to Stroustrup, C++ exception handling (EH) is not intended to handle signals or other low-level, OS-specific events such as arithmetic exceptions. Win32 Structured Exceptions (SEs) clearly fall into this category, and it should not be possible to catch SEs in catch(...). However, the C++ Standard doesn't specifically forbid this, and because anytime you raise an SE you invoke undefined behavior, it's "legal" for catch(...) to catch SEs, in a very technical sense, because the C++ Standard imposes no requirements on the behavior of a program that does something undefined, such as dereferencing a NULL pointer. That said, while it may seem convenient to catch truly everything in catch(...), catching SEs there is the source of numerous problems. Before discussing why I say that, let's consider how Visual C++ is documented to behave.
Visual C++ 5 and later define two EH models, called synchronous and asynchronous. The model chosen is determined by the /EH command line option. /EHs specifies the synchronous model, while /EHa specifies the asynchronous model. There is also /GX, which is defined by default for MFC and other AppWizard applications. /GX is equivalent to /EHsc, so it selects the synchronous model. (The c indicates that extern "C" functions do not throw exceptions.) The VC++ documentation defines the asynchronous model as follows:
In previous versions of Visual C++, the C++ exception handling mechanism supported asynchronous (hardware) exceptions by default. Under the asynchronous model, the compiler assumes any instruction may generate an exception.
Under the asynchronous model, catch(...) catches SEs, and you must use /EHa if this is what you really want. You must also use /EHa if you're expecting to catch SEs that have been translated into C++ exceptions with the help of _set_se_translator(). (See Q4.)
The synchronous model is described as follows:
With the new synchronous exception model, now the default, exceptions can be thrown only with a throw statement. Therefore, the compiler can assume that exceptions happen only at a throw statement or at a function call. This model allows the compiler to eliminate the mechanics of tracking the lifetime of certain unwindable objects, and to significantly reduce the code size, if the objects' lifetimes do not overlap a function call or a throw statement.
The synchronous model is intended to provide C++ EH as Stroustrup intended, but unfortunately, in Visual C++ 5 through Visual C++ .NET 2003, it doesn't behave exactly as documented, and it's still possible to catch SEs in catch(...) if you compile without optimizations, or you compile with optimizations, and the optimizer is unable to determine the tried code cannot throw a C++ exception. For example, in VC5, if the tried code calls a function, the optimizer assumes it can throw, while in VC6, the function may need to live in another translation unit (source file) to cause the optimizer to be pessimistic. Visual C++ .NET 2005 at last corrects this problem for the synchronous model.
Q3. So what are the consequences of catching Win32 Structured Exceptions (SEs) in catch(...) ?
A. In order to answer this question, we first need to discuss what C++ exceptions and SEs represent. According to Stroustrup, C++ exception handling is error handling. For example, failure to acquire a resource such as memory or running out of disk space while writing to a file is an error that is often best reported by throwing an exception, especially when the resource is normally expected to be available. This greatly simplifies code by eliminating the need to check function return codes, and it helps you centralize error handling. This sort of error can occur in a correctly written program, and that is what C++ EH is intended to address.
On the other hand, SEs typically represent program bugs. Everyone is familiar with access violations resulting from dereferencing NULL pointers. The hardware detects this and traps, and Windows turns the hardware event into an SE. In general, SEs represent programmer errors, and correctly written programs have no such errors. SEs are also used in the normal operation of the system. For example, it's possible to use VirtualAlloc() to reserve a region of your address space and dynamically commit pages as a program accesses uncommitted memory and causes page faults. The program catches the SE in an __except clause, commits the memory, and resumes execution with the instruction that caused the fault. This should be invisible to C++ EH, which should not be able to interfere with it.
C++ exceptions and Win32 structured exceptions represent very different things. Problems caused by homogenizing them in catch(...) include the following.
// Begin exception-free code
... Update critical data structure
// End exception-free code
try
{
TheFastButResourceHungryWay();
}
catch (...)
{
TheSlowButSureWay();
}
If a program bug or compiler code generation bug causes an access violation in the tried function, your discovery of the bug is hindered by catch(...) swallowing the SE. The only manifestation of the bug may be an inexplicable slowness, which may not be apparent in your testing, while if catch(...) hadn't caught the SE, you certainly would have discovered the bug while testing. (OS error boxes are pretty hard to miss!)Q4. What about _set_se_translator?
A. _set_se_translator is a function used to register another function which translates Win32 structured exceptions into true C++ exceptions. It allows you to partially avoid the catch(...) problems described in Q3 by writing the following, where se_t is the type of object thrown by the translator function:
catch (se_t) { throw; }
catch (...) { ... } This is not a great workaround, because it's easy to forget to augment every catch(...) as shown above, and you would have to establish a translator in every thread you create that runs code which uses this method, because SE handlers are attributes of a thread, and calling _set_se_translator in one thread has no effect on other threads. Also, the translator function isn't inherited by new threads; thus, _set_se_translator has no effect on threads created after it's called. Besides being difficult and error-prone to implement, this workaround can't account for code you didn't write and can't modify, and this can be an issue for library users.
Finally, the documentation does not make it clear that to use _set_se_translator reliably, you must select the asynchronous EH model discussed in Q2, and that tends to bloat your object code. If you don't do this, your code is subject to the optimization discussed in Q1.
Q5. How do I deal with all this?
A. When using Visual C++ 5 through Visual C++ .NET 2003, the best course is to avoid catch(...) whenever possible. If you must use catch(...), be aware of all the issues described in the preceding questions. If you're using Visual C++ .NET 2005, the /EHs option behaves as documented, the synchronous model works correctly, and you don't have to worry about catch(...) catching SEs.
Q6. How do I safely use _com_error, std::exception, and other non-MFC exception classes in MFC programs?
A. MFC was designed before Visual C++ supported C++ exception handling. The original MFC implementation was based on macros such as TRY and CATCH and used setjmp and longjmp to simulate C++ exception handling. To simplify this initial implementation, MFC threw pointers to CException objects and pointers to objects of classes derived from CException, and CException* was the only exception type supported by early versions of MFC. Though MFC was updated to use C++ exceptions in Visual C++ 2.0, it was never made aware of other exception types, and the MFC source code continues to use the macros, which are now defined in terms of C++ EH. For example, MFC defines CATCH_ALL in terms of:
catch (CException* e)
Clearly, this doesn't catch all exceptions if the tried code uses the C++ Standard Library, compiler COM support, or other libraries that define their own exception types. MFC does not itself use any exception type other than CException*, but in many places, it wraps your code as follows:
TRY
{
// Call your code
}
CATCH_ALL(e)
{
// Clean up and perhaps report the error to the user
}
END_CATCH_ALL
For example, an MFC WindowProc is guarded this way, because exceptions aren't allowed to cross Windows message boundaries. However, CATCH_ALL catches only MFC exceptions, and if you fail to catch a non-MFC exception yourself, your program will be terminated due to an uncaught exception. Even if you do catch the exception yourself, where you catch it is still very important, because there are a number of functions within MFC that expect to catch all exceptions so they can clean up or return an error code to the caller through a normal function return statement. Now, if the try blocks within these functions call into your code, and you don't translate non-MFC exceptions into MFC exceptions right then and there, you allow non-MFC exceptions to propagate through MFC code that expects to catch everything, and as just described, it can't, and it doesn't. You may end up skipping some important clean-up code, and even though you catch your non-MFC exception at some outer level, it may be too late. This suggests the following rule of thumb:
Never allow a non-MFC exception to pass through MFC code
At a minimum, this means protecting every message handler that could exit via a non-MFC exception with try/catch. Now, if a message handler can't do anything about an exception, and you want it to be reported to the user, it's often appropriate for the handler to exit via an exception, because MFC will present the user with a nice message box describing the error, provided it can catch it. To achieve this result, you need to translate non-MFC exceptions into MFC exceptions. Macros can help here. For example, consider the code sketched below:
class MfcGenericException : public CException
{
public:
// CException overrides
BOOL GetErrorMessage(
LPTSTR lpszError,
UINT nMaxError,
PUINT pnHelpContext = 0)
{
ASSERT(lpszError != 0);
ASSERT(nMaxError != 0);
if (pnHelpContext != 0)
*pnHelpContext = 0;
_tcsncpy(lpszError, m_msg, nMaxError-1);
lpszError[nMaxError-1] = 0;
return *lpszError != 0;
}
protected:
explicit MfcGenericException(const CString& msg)
: m_msg(msg)
{
}
private:
CString m_msg;
};
class MfcStdException : public MfcGenericException
{
public:
static MfcStdException* Create(const std::exception& ex)
{
return new MfcStdException(ex);
}
private:
explicit MfcStdException(const std::exception& ex)
: MfcGenericException(ex.what())
{
}
};
#define MFC_STD_EH_PROLOGUE try {
#define MFC_STD_EH_EPILOGUE \
} catch (std::exception& ex) { throw MfcStdException::Create(ex); }
The code above defines a class, MfcGenericException, which is derived from MFC's CException, and which serves as the base class for MfcStdException and other non-MFC exception types. (We need this base class because MFC does not provide a generic exception type that encapsulates a message string.) The macros at the bottom are intended to surround your message handlers and other code called from MFC that can throw non-MFC exceptions. You use it like this:
void MyWnd::OnMyCommand()
{
MFC_STD_EH_PROLOGUE... your code which can throw std::exceptionMFC_STD_EH_EPILOGUE
}
Together, the macros guard your code in a try block, and the MFC_STD_EH_EPILOGUE macro translates std::exception into something MFC can catch, in this case, MfcStdException. Note that MfcStdException has a private constructor and defines a static Create function, and the latter provides the only way to create an MfcStdException. It ensures the exception object is created on the heap, which we must do, because each object maintains state information in the form of its error message. We can't simply throw a pointer to a static instance, as AfxThrowMemoryException does, because that wouldn't be thread-safe due to our state information, and it's also possible to throw and catch an exception while handling another, which is ultimately rethrown, and that would tend to overwrite the first message. We can't take any shortcuts here! Whoever catches our exception is responsible for calling its Delete member function, inherited from CException. This function will delete the MfcStdException object, and it's good to disallow mistakes such as throwing a pointer to a local object by preventing the creation of local objects altogether.
Using a technique such as the above is essential to creating MFC programs which are robust in the presence of heterogeneous exception types. It's much easier than writing explicit try/catch blocks, and it allows exceptions to propagate to whoever can best handle them. In fact, explicit try/catch blocks are relatively rare in well-designed programs, because the code is written in such a way that the automatic stack unwinding and local variable destruction does the right thing. Consequently, the final step of handling an exception often amounts to simply letting the user know something went wrong, and by translating your non-MFC exceptions into MFC exceptions, MFC can handle that just fine.
To comment on this page, please send email to dsh@mvps.org.
| 标签：微软亚洲研究院 图像去雾 cvpr 最佳论文 研究心得 论文背后故事 | 分类：技术 |
作者：何恺明
那是2009年4月24日的早上，我收到了一封不同寻常的email。发信人是CVPR 2009的主席们，他们说我的文章获得了CVPR 2009的最佳论文奖(Best Paper Award)。我反复阅读这封邮件以确认我没有理解错误。这真是一件令人难以置信的事情。
北京灰霾照片的去雾结果
CVPR的中文名是计算机视觉与模式识别会议，是计算机视觉领域最顶尖 的国际会议之一。今年的CVPR共收到约1450篇投稿，其中393篇文章被接收，接收率为26%。只有一篇文章被选为今年的最佳论文。这是CVPR创立 25年以来首次由中国人获得这个奖项。这篇文章是我在微软亚洲研究院形象计算组实习的时候完成的，也是我个人真正意义上写的第一篇论文。
简单有效的图像去雾技术
这篇论文研究的问题是图像的去雾技术，它可 以还原图像的颜色和能见度，同时也能利用雾的浓度来估计物体的距离，这些在计算机视觉上都有重要应用（例如三维重建，物体识别）。但是之前人们还没找到简 单有效的方法来达到这个目的。在这篇论文里，我们找到了一个非常简单的，甚至说令人惊讶统计规律，并提出了有效的去雾方法。
与之前的方法不同，我们把注意力放到了无雾图像的统计特征上。我们发现，在无雾图像中，每一个局部区域都很有可能会有阴影，或者是纯颜色的东西，又或者是黑色的东西。因此，每一个局部区域都很有可能有至少一个颜色通道会有很低的值。我们把这个统计规律叫做Dark Channel Prior。直观来说，Dark Channel Prior认为每一个局部区域都总有一些很暗的东西。这个规律很简单，但在我们研究的去雾问题上却是本质的基本规律。
由于雾总是灰白色的，因此一旦图像受到雾的影响，那么这些本来应该很暗的东西就会变得灰白。不仅如此，根据物理上雾的形成公式，我们还能根据这些东西的灰白程度来判断雾的浓度。因此，我们提出的Dark Channel Prior能很有效地去除雾的影响，同时利用物的浓度来估算物体的距离。
电脑游戏带来的灵感
这个想法的产生来自于两个偶然的观察。
第一个观察来自一个3D游戏。这个游戏有很多带有雾的场景，但这些场景 都是虚构的不实在的东西。计算机生成的3D图像会与自然图像的统计规律有很大区别，但人的视觉系统却仍然能感觉到虚拟图像中存在的雾。这让我相信，人的视 觉系统一定有一种有效的机制来感知有雾的图像，而且这种机制一定与现存的去雾方法不一样。前人提出的去雾方法都把重点放在图像的对比度上，但虚拟场景和现 实场景在对比度上的统计规律会很不一样。人的视觉系统仍然能够感知虚拟场景中的雾，说明除了对比度以外，人眼一定还在利用别的东西来感知雾。所以我觉得， 这个问题里一定有人们未曾发现的更接近本质的东西。
第二个观察来自对前人的去雾方法的研究。之前最有效的去雾方法是Fattal在2008年的Siggraph文章《Single Image Dehazing》中提出来的，这篇文章是我们首要超越的目标。这篇文章里给出的比较结果中，我发现一种叫做Dark Object Subtraction的方法有时候会有更好的效果。这种方法利用了全图最暗的点来去除全局均匀的雾。如果雾的确是均匀的，这种方法就会更有效。其缺点在于它无法处理不均匀的雾，而这却正是去雾问题中的难点。因此自然的想法就是局部利用Dark Object Subtraction处理图像。而恰巧这样做并不需要利用对比度，说明它与之前的方法有了本质的区别。让人吃惊的是，在大量的实验中，我发现这么简单的想法，其效果却非常好。
但我们论文中最重要的观点却形成在我动笔写文章之后。在文章的前几稿 中，我在形象计算组的mentor孙剑一直追问我，我们的方法能成功的本质原因是什么，背后有什么我们没有充分理解透彻的“真知灼见”。尽管我们有很简单 的方法，也有很漂亮的实验结果，但我们却无法让人对这种方法的有效性感到信服。这是因为我们还讲不出个道理来。带着这个问题，我又回到了实验和观察之中。 我发现，既然大量实验结果证实局部做Dark Object Subtraction的做法是成功的，那么就说明去雾之后的图像的每个局部的确是有暗的物体存在的。也就是说，在这个方法成功的背后，其实有一个关于无 雾图像的统计规律。我的mentor孙剑让我去先去研究一个无雾图像的数据库。通过大量的实验，我们发现这个统计规律是客观存在的。这就是我们所提出的 Dark Channel Prior。
这是我写的第一篇论文
2007年，我从清华大学基础科学班本科毕业，之后就读于香港中文大 学。在基础科学班的主修课程是数学和物理，因此在本科阶段，我并没有系统地学习过计算机方面的相关知识。出于兴趣，我选修了计算机图形和图像方面的一些相 关课程。但是在进入微软亚洲研究院实习的初期，这些基础课程远远不足以应付我面对的研究工作。背景知识的缺乏使我在入门的路上举步维艰。在阅读文章的时 候，我常常都不知道哪些是大家都在用的方法，哪些才是作者的贡献。对我来说，我看见的每一样东西都是新的。
在面试的时候，我的导师汤晓鸥就跟我说过，他并不在意我没有相关的背景 知识，因为所有相关的东西都是可以学的。在进入微软亚洲研究院实习的头一年里，我在mentor孙剑的指导下做过几个不同的课题，虽然都没有成功，但从中 学习了不少知识。其中我花了大量时间研究的image matting问题 (半透明物体边界提取)，就对这次的文章有很大帮助。在刚开始研究去雾的时候，我就发现雾的方程和matting的方程非常相似，而我之前所研究的 matting框架可以给去雾带来帮助。利用这个框架，我只需要寻找一个能局部估算雾的浓度的方法就行了。这个框架使得我能专心的寻找这样的方法并且最后 提出了Dark Channel Prior。
纽约、北京灰霾照片的去雾结果
即使有了想法和实验结果，第一次写文章也使我觉得非常困难。我经常陷入 自己和自己吵架的角色当中。在每一段话写好之后，我常常会质问自己事情到底是不是这样的，这其中有没有漏洞。我也会问自己，如果我是评委，或者是读者，那 么我能看懂这篇文章吗，我怎么写才能让思路更加流畅。就在这样的挣扎中，一稿通常要写好几天。而即使是这样，起初的几稿也远没能让孙剑满意。一开始，他只 在文章的结构、思路和观点的提出上给我建议，而不去具体修改我的文章。于是我又回去继续和自己吵架。但每当我把自己说服了，孙剑还是总能提出新的质疑。就 在这样的循环中，终于有一天孙剑说文章已经写得不错了，他才开始具体的修改。正是这样的苛刻要求，才会有后来高质量的文章。
大道之行在于简
我们这篇文章的三个审稿人都给出了最高的评分。他们认为我们的方法简单 而有效。其中一位评委说，Dark Channel Prior的想法听起来很不可思议，但我们却证明了其真实性。另一位评委认为很少有文章能够用如此简单的方法使实验结果获得如此大的提升。还有一位评委甚 至亲自实现了我们的方法并确认其可行。孙剑说阅读这样的评审结果是一件让人快乐的事情。而汤老师认为，这篇文章的成功在于三个方面。第一，方法非常简单； 第二，对于一个很困难的问题，给出了很好的结果；第三，发现了一个基本的自然规律并且应用在实际的问题中。在迈阿密的演讲结束后，观众也给予了很高的评 价。他们跟我说，这是这次CVPR上最有趣的一个演讲。
一位与会的研究员说，最好的idea，往往就是那些看起来很简单，但说 出来大家都会觉得怎么没有人想到过的idea。而我们的idea正好就符合了这一点。我们论文摘要的第一句话是这么说的，“我们提出了一个简单而有效的方 法”。或许，这就是对我们这次工作最好的概括——简单的，就是美的。
作者介绍
何恺明:微软亚洲研究院视觉计算组实习生，现就读于香港中文大学讯息工程多媒体实验室，本科毕业于清华大学基础科学班。他是2006年微软小学者奖获得者，2003年广东省高考状元本报讯记者崔朝阳报道：广东省公安厅近日在对省人大代表的建议答复中表示，可快速发现、识别和截查套牌车的卡口系统有望年内在广东全省范围投入使用，为加大对套牌车的打击力度，公安厅还拟提请省人大常委会修订《广东省道路交通安全条例》，加大对查处套牌车的处罚力度。
今年初的省“两会”期间，陈进德等6名省人大代表提交建议指出，套牌车难发现、难查处、轻处罚，全省交警系统没有形成有效的联动措施，是套牌车层出不穷的重要原因。
省公安厅表示，针对目前对套牌车处罚过轻，公安厅目前正会同省政府法制办开展调研，拟在年内提请省人大常委会修改道路交通安全条例，增加限制违法行为人人身自由（拘留）、加大罚款额度、没收违法车辆、追究刑事责任等条款，增加违法人违法成本。
此外，对套牌车，广东已建立全省范围的套牌车黑名单库，将套牌车号码都录入库中，部署全省警力查询。具有号牌识别功能、一旦发现盗抢机动车或假号牌车自动报警的卡口系统，预计年内可投入使用。
代表在建议中还提出，应增加车牌科技含量，让真牌不易被仿造，假牌更易被识别。对此，公安厅表示，该厅还在研发电子车牌，未来的电子车牌中将置入电子芯片，建立车牌电子身份认证系统，确保车辆唯一性，从源头上根除套牌车。
记者今晨从省公安厅交管局了解到，由于车牌制作涉及国家统一标准问题，公安厅已就此上报国家相关部门，目前还在等待批复。
1.变脸 Face Off
2.超我 Superego
3.小王国与大盗
4.羊驼
作者：申音 《创业家》杂志前执行主编
时光倒流20年。
那是1989，柏林墙倒塌的时刻。整个世界都在关心着冷战的终结、民主的胜利、意识形态的巨变。
但有两个家伙根本不关心政治。
一 个是34岁的史蒂夫。乔布斯，这位"硅谷金童"的人生正处于低谷。在被自己参与缔造的苹果电脑公司赶出来后，他为了复仇创办的Next和低价买下的 Pixar都处于入不敷出、岌岌可危的境地。这位昔日全美最富有的人之一（远远超过那时的比尔。盖茨），私人财产只剩下2500万美元。
而另一个是27岁的史玉柱。刚刚硕士毕业的他瘦得可以被风吹倒。跟那个年代大多数的热血学子们相比，史玉柱没有狂热的政治理想，他一心想的是如何找梯子登上商业舞台。
20年的跌宕过后，乔布斯和史玉柱已分别成为各自国家商界的标志性人物。而当年关心政治的人们如今只关心经济了。
不过，还没有人去认真地比较一下乔布斯和史玉柱。更没有人去思考：为什么美国没有史玉柱，中国没有乔布斯？
这其实是一件很有意思的事情。
精彩摘录：
・两人还是洞悉人性的营销天才。只不过一个靠发掘人性的美好赚钱，而另一个利用人性的弱点来抢金。
・两个理想主义的青年，一个变成了真正的商业梦想家，为了创造未来他不惜调动一切资源。而另一个人转变为纯粹而现实的商人，精确地计算着自己的付出与回报，不再做那些费力不讨好的事。
・中国并不缺乏伟大的商人，比如胡雪岩、张謇、卢作孚，但他们死了，人们如今只记得一些轶事；而熊彼得定义的企业家过去了，他们还能留下激动人心的产品和伟大的公司。
・美国梦的真正含义是什么？是给一个理想主义者提供梦想成真的舞台。那么中国梦呢？是不是逼着一个理想主义者向现实妥协，最终自己成为这个环境的一部分，才能成功？
变脸 Face Off
在我看来，乔布斯和史玉柱的人生经历就像是同一个剧本大纲拍出的两部电影，只不过更换了不同的导演和时空场景。
两人都是本国知识青年里的佼佼者，脑子好使还天不怕地不怕，早早投身高科技领域创业，并在三十岁左右就达到了事业的第一次高峰。
1983年，年仅28岁的乔布斯登上了《时代》周刊的封面，他被看成是"个人电脑的真正发明者"。1992年，在一个国内十大城市万名青年的问卷调查中，史玉柱名列"最受崇拜的青年人物"第二位，第一名是比尔。盖茨。
两人都习惯于蔑视陈规、特立独行，带着点邪性的"范"，一个永远的黑色套头衫配牛仔裤，而另一个光头红白运动衣。
他俩都有着与生俱来的商业敏感，是真正的跨界高手。乔布斯在PC、音乐、电影、手机等多个领域都证明了自己的能力，而史玉柱则在软件、房地产、保健品、金融投资、网游等战场纵横驰骋。
两人都是执着的完美主义者，都能把一个产品做到惊天地泣鬼神。卖了10年的脑白金仍是中国最畅销的保健品，而iPod则占据了数字音乐播放器市场的70%.此外，两人还是洞悉人性的营销天才。只不过一个靠发掘人性的美好赚钱，而另一个利用人性的弱点来抢金。
或许是因为成功来得太过迅速，他们先后导演过自毁式的高速坠落，幡然醒悟之后，又表现出惊人的自我纠错能力，并重新勾画一条不断向上的弧线。
曾经有那么一段时间，史玉柱看起来就要成为中国的"乔布斯"。从1989年起，他每一年都要推出一款自主开发的产品，从M-6401桌面排版软件、M-6402文字处理软件到巨人汉卡，再到巨人中文手写电脑、巨人财务软件等等。巨人飞快地成长为一个年产值10亿、利润数千万的高科技集团公司，其年度销售商大会更成为全国规模最大的电脑盛会。
几乎与此同时，乔布斯只剩下几千万美元的现金，和两个面临着裁员重组的问题公司，他完全可能成为美国版的"史玉柱"，比如在加州搞房地产，去拉斯维加斯 开赌场，到中东倒腾石油，或者变成一个精明的股权投资人。但他什么都没有干，只是继续掏自己和别人的腰包来支持两个长期赔钱的公司，固执地等着它们出现转 机。
某种程度上，乔布斯是幸运的。在美国，他的理想主义总能找到合适的欣赏者，所以他可以咬牙不向现实妥协。像罗斯。佩罗这样的前辈创业家愿意签出支票，并与其分担风险。迪斯尼这样的大公司也同意投资给小公司Pixar，让其制作动画长片并参与分成。
而史玉柱之所以蜕变成今天的史玉柱，是因为他发现，做软件公司为他意外地赢得了名声，而在中国，名声就意味着许多新的机会。
在邓小平南巡讲话之后，史玉柱恰逢其时地被媒体和政府发现。很快，他被评为"中国十大改革风云人物"、"广东省十大优秀科技企业家"等，获得了珠海市第二届科技进步特殊贡献奖，一位总把裤带提到胸下的最高领导视察后题词说"中国就应该做巨人"。
你可以不关心政治，但政治会来关心你。
为了支持这个"高科技楷模"，当地政府以不到当时市价1/4的价格给了史玉柱一块市中心地皮盖楼（350/平米地价，2007年珠海的平均地价已经是 3500/平米）。而在若干位更高层领导的直接鼓励下，他把计划一改再改，从原来的自用变成了商用，从最早的19层变成72层（全中国第一高楼），预算从 2亿变成了12亿元。
单纯软件业务的回报根本不足以支撑这样高的资金投入，于是史玉柱中断了技术创新，开始卖楼花、运作保健品、搞服装，杀入更加暴利的行业。最后因为由于工程拖期、宏观环境的恶化，导致整个公司的资金链断裂，巨人大厦从此沦为中国最著名的"烂尾楼"，直到今天。
有意思的是，1998年，背负着2亿巨债的史玉柱想要东山再起。他又算了一笔账，搞软件虽然利润很高，但市场相对有限，如果要还清2亿元，估计要10年；保健品不仅市场大而且刚起步，做脑白金最多5年（实际上只用了3年）。
事实证明，他的选择居然又是对的。
超我 Superego
一个人的性格，会成为他今后命运方向的指针吗？
乔布斯，一个私生子，在中产阶级养父母的宠爱下长大，自卑与自大的双重人格。他的理想主义是与强烈的领地意识、以及咄咄逼人的攻击性混合在一起的。
乔布斯早年的密友、曾经一起吸毒、一起去印度朝圣的丹尼尔。科特克说："史蒂夫心中总是装着他的苹果电脑。从更深层次上分析，他的成功是由于其 内心总有一种深切的不安全感，正是这种不安全感使他必须出去闯荡以证明自己存在的价值。另外，由于他从小就知道自己是被收养的孩子，他的行为并不被大多数 人理解……"
就像《星球大战》中安纳金天行者。这种内心深处的"原力"，与加州的硅片、晶体管结合起来，苹果公司诞生了。正如伊甸园里蛇诱惑亚当和夏娃吃下的那个苹果，甜美而带有一点"邪恶"。
事实上，在苹果电脑早期的发展中，沃兹的技术、马库拉的资本运作、斯科特的管理和乔布斯的远见几乎一样重要，但作为公司董事局主席，乔布斯的个人魅力，让他轻易成为了公众关注的中心，并几乎独享了上市成功后的光环。
随着创业伙伴们因为各种原因一个个隐退，他越来越认为自己才是"点石成金"的超级人物，可以将个人凌驾于公司之上。硅谷最著名的投资人之一、当时苹果的董事会成员阿瑟。洛克回忆说："那时，乔布斯刚愎自用，满脑子主意，肆意而为，毫不考虑公司的前途。"
按照佛洛依德的理论分析，乔布斯的自我（ego）逐渐被本我（id）所控制，他被原力的黑暗面所吸引，并一步步走向公司的对立面，终于被董事会放逐。
而那个来自安徽小镇怀远，独自闯荡大城市的青年同样拥有着强大的内心世界，激励他的是一种英雄主义情结。
事实上，史玉柱出生的环境里根本连个晶体管都找不到，当乔布斯和沃兹开始组装第一台计算机的时候，他还只能对着《十万个为什么》自制土炸药。更不用说预判到"一人一台电脑"的产业未来呢？
对于以嬉皮士自居的乔布斯而言，电脑恰好是能帮助他释放旺盛的Libido（欲望）的媒介罢了，但对于史玉柱来说，电脑则是帮助他改变命运的唯一工具。否则他只能像刘震云小说《单位》里的大学生小林一样，过着按部就班的生活。
1984年，在乔布斯策划的那则著名广告里，苹果的女模特挥锤砸烂了"Big Brother老大哥"。在PC世界里，谁都知道"老大哥"就是IBM. 1990年，身高1米80、体重不到120斤的史玉柱给自己的新公司起了一个非常响亮的名字――"巨人"，他宣布，巨人要成为中国的IBM，东方的巨人。
这很容易让人联想起2000多年前的刘邦，他在见到秦皇车驾时的感叹，"大丈夫当如是也"。而另一个叛逆者项羽，说的是"彼可取而代之"。
这种自我赋予又被外界不断强化的使命感贯穿了史玉柱创业的前半程。熟读毛选，青年楷模，大跃进式的增长目标，军事化的企业管理，为自己为城市树立一座固化的丰碑……
终于有一天，这些使命变成了他再也承受不起的包袱，庞大的"巨人"分崩离析。三年后，在经历了对人性和坏境的彻底反思，一次次自杀的念头和被追杀的恐惧之后，一个完全理性的、成熟的、内心更强大的史玉柱回来了。
他彻底放弃了珠海时期的企业文化"做中国的IBM"，"这是非常害人的一个空想，制定了一个很虚的目标。它在鼓励什么，鼓励大家搞大跃进、搞浮夸，让大家心里面很浮躁，对于现实没有什么帮助，现在我就不搞那个宏伟的目标了，我觉得实用最关键。"
新的文化很直白，"说到做到、只认功劳、严己宽人、敢担责任、艰苦奋斗。"这是在黄山太平湖，柳传志教给他的。
史玉柱不再把自己当成一个"知识分子"，他坦言"胆子越来越小"，"只做好商人必须做的事情"。在一个只有"锦上添花"没有"雪中送炭"的现实 环境里，他找到了正确的生存策略。让企业永远保持充沛的现金流，负债率低于30%；只做高利润率又不跟政府沾边的生意（这样的生意常常处于灰色地带）；既 然银行不肯借钱，就干脆参股银行；及时把公司变现，玩资本财技（上海健特借壳、巨人上市融资近10亿美金）；跟有合法伤害权的媒体保持恰当的距离又给予充 分的好处。唯一遗憾地是，他对创新不再有兴趣。
乔布斯在"荒野"中被放逐的时间更长。尽管他的坏脾气改变有限，但他学会了宽容和谦卑，知道怎么信任和授权给优秀的人，比如Pixar总裁约 翰。拉赛特，乔纳森。埃弗。这个设计白色马桶的英国人，后来在苹果公司担当设计副总裁。他学会了合作与开放，让微软入股，用英特尔的芯片，建立了 iPhone开放平台。
人们的第一次成功往往根源于欲望和运气，而第二次乃至更多的成功则需要智慧和自控。
无论乔布斯还是史玉柱，最终都通过克制本我，实现了自我超越（Superego），这才是他们真正的魅力所在……
不同在于，两个理想主义的青年，一个变成了真正的商业梦想家，为了创造未来他不惜调动一切资源。而另一个人转变为纯粹而现实的商人，精确地计算着自己的付出与回报，不再做哪些费力不讨好的事。
小王国与大盗
其实，道德感与一个人的成功并无太大关系。
在硅谷，与乔布斯的天才同样闻名的是他的傲慢自负、喜怒无常、抠门小气、巧取豪夺、冷漠无情。前时代周刊的记者，日后红杉投资的大佬迈克。莫里茨，曾把在乔布斯威权统治下的苹果称之为"小王国"（Little Kindom），这是一个非常准确的描述。
专制带来效率，难得乔布斯的个人品味和商业直觉又皆属一流。不过，如果乔布斯生在中国的话，一个传统意义上的"臣民社会"而非"公民社会"里，他的自大会惯坏他，人们会完全屈服于他的权威，听从他的指令，直到他最终把公司毁灭，就像牟其中、唐万新、孙宏斌这些人一样。
但他生在美国，民主社会和资本主义机制里有种天生的"对冲"力量。董事会、股东大会、机构投资者像一道道紧箍咒约束着他。默认的游戏规则是，只要你有能力做大公司的价值，就算你是个暴君也无妨；反之，等待你的就是自动下台或者政变逼宫。
在中国，大多数民营企业和其创始人的命运，缠绕得太紧密了。权力的垄断和资本的垄断密不可分。我们没有发明出一套"防火墙"的制度，能将创始人的个人行为、个人信用与企业分离开。
于是，考察企业家自身的道德品质，变成了一件无比严肃又异常困难的事情。
相比大多数国内同行，史玉柱，堪称私德无缺。他信守承诺、有情有义、高度放权、慷慨分利，在公司破产之后，其核心团队成员仍不离不弃，甚至拿自己的钱来补贴公司。而他二次创业成功后，主动还债两亿的壮举，也足以表率。
在后来的巨人集团内部，史玉柱甚至成功地创造了一个"民主管理"的小环境。他成立了七人执委会，任何决策都必须多数票才能通过。除了核心产品，日常人财物管理全部放手，文秘出身的总裁刘伟，事实上已扮演了CEO的角色。
在《庄子。外篇》中，大盗盗跖（传说是贤人柳下惠的弟弟）与他的徒弟谈论"盗亦有道"。跖曰："夫妄意室中之藏，圣也。入先，勇也。出后，义也。知可否，智也。分均，仁也。五者不备而能成大盗者，天下未之有也。"
五者皆备的史玉柱，在现实的商业世界里扮演一个"Big Brother"的角色，通过排山倒海的营销攻势，淹没一切反对声音。居高临下地制订规则，利用消费者的无知、贪婪和权力欲，还有既懒惰而又想过瘾的心 理，设计出各种圈钱的工具（详见《南方周末》的文章《系统》）。
史玉柱直言，"商业是什么？商业的本质就是在法律法规许可范围内获取最大利益。我是一个商人，做的事情就是在不危害社会的前提下为企业赚取更多利润。要一个商人又要赚钱又要宣扬道德，那不是商人，而是慈善家。"
而视道德为无物、几乎从未在慈善事业上捐出一毛钱的乔布斯，从iMac、iPod到iPhone，他所推动的一切都是在迎合"YOU"这个消费 者主权的时代。过去唯我独尊、四面树敌的苹果，开始走向一种新的理念：用户要的不是技术，甚至不是电脑，而是利益的最大化和体验的最优化。
他不再把苹果视作一家电脑公司，归根结底，"我们骨子里就是一家消费品公司，你的生死存亡掌握在消费者的手中。他们才是我们关注的对象。我们觉得自己的工作就是对整个用户体验负责。如果表现不及格，那就是我们的错。错就一个字。"
这是不是"民主"精神在商业里的最好体现？
羊驼
1995年，史玉柱名列《福布斯》中国百富榜第8位，当时他是唯一一个搞高科技的企业家。
2009年，史玉柱仍然是《新财富》500富人榜中，排名最高的与新经济有关的富豪。在他后面的是李彦宏、马化腾、施正荣等。
看《枪炮、病菌与钢铁――人类社会的命运》一书，美国生物历史学家贾雷德。戴蒙德谈到了一个有趣的问题：为什么14种被驯化的大型哺乳动物有13种来自欧亚大陆，为什么欧亚大陆的牛、马、绵羊、山羊、猪，而不是南美洲的羊驼，成为最终广泛分布于全世界的牲畜？
他的答案是环境。最主要的原因是，欧亚大陆由于其广大的面积和生态的多样性，拥有最多的可驯化的候补动物。而这些驯化动物又促进了欧亚大陆民族的繁荣，进而帮助后者征服全世界，而这些动物跟随着征服者遍及其它大陆。
在商业世界里，存在着相似的问题。在过去100年中，为什么以美国为首的少数4-5个国家，而不是剩下的100多个国家，集中产生了几乎所有对社会进步至关重要的创新？几乎定义了这个星球所有成功的商业模式？
史玉柱和乔布斯，两个同样具有商业天赋，且性格背景相似的创业者，最终一个变成垃圾商品的成功贩卖者，而另一个成为这个星球上最具创造力的企业家。
当乔布斯在斯坦福的演讲"Stay hungry，Stay foolish"可以影响全世界青年的时候，史玉柱在《赢在中国》里的语录却只能供本土创业者琢磨。
每个社会里都可以孕育出潜在的商业天才。而真正的商业天才，在任何环境下都有可能成功的。
但在某些环境中成长出来的商业，就像南美安第斯高原的羊驼。看着很可爱很善良，经济价值很高，但是却无法大规模的繁衍和推广。
美国梦的真正含义是什么？是给一个理想主义者提供梦想成真的舞台。那么中国梦呢？是不是逼着一个理想主义者向现实妥协，最终自己成为这个环境的一部分，才能成功？
"当巨人一步步成长壮大的时候，我最喜欢看的是有关成功者的书，当巨人跌倒之后，我看的全是失败者的书，希望能从中找出站起来的力量。"史玉柱说。
在2000年CCTV的一次《对话》节目中，史玉柱谈到了所谓"理想的状态，就是说今后市场经济发育到一定时候，法制环境建立，然后就是政企脱 钩，我最希望的是一个什么样的环境：就是一个政府包括国家领导人，省级领导人，包括地方领导人，他做他的事，我们企业做我们企业的事。就等于你这个领导人 你定游戏规则，然后我们这些人就按你游戏规则做事。最好是不要有什么太多的接触，我就是这个意思。巨人大厦这个问题上，不管哪一级的领导人没有任何的责 任，责任全是我的。"
当一个人把所有的问题都归咎于内因的时候，是因为他意识到自己改变不了外在环境，能改变的只有自己。
其实近代以来，中国并不缺乏伟大的商人，比如胡雪岩、张謇、卢作孚，但他们死了，人们如今只记得一些轶事；而熊彼得定义的企业家过去了，他们还能留下激动人心的产品和伟大的公司。
今天，中国可能是唯一一个创业热情甚至比美国更高的国家。各级政府鼓励"以创业带动就业"，启动创业板，政府成立风险投资基金。这些都是好事。 但必须承认，我们仍然是一个缺少知识产权保护，国家垄断资源和与之相关的分配权，资本更青睐与权力结合而非知识，优秀的年轻人希望跻身公务员之列的社会。
哪些被乔布斯所激励的创业者们，最终会不会变成为史玉柱的信徒呢？
这是一个问题。
