月福洗车造成车漆多处划痕

周末在月福奥运村店洗车，从自动洗车的隧道出来后停到擦车的位置上，然后有两个工人开始擦，我们就出去了。回来后直接开车回了家。到家停车后，发现车前盖上有多处深浅不一，长度各异的划痕，遍布前盖。划痕方向不一，从其走向来看，像是在用带硬物的布擦车的时候造成的。

具体是自动洗车时划的还是工人擦的时候划的，我不能确定。但有一点是确定的，那就是这些划痕洗车前肯定没有。在路上跑一会儿怎么也不可能给前盖上造成划痕的。气愤之余，想找他们去。但一想，他们绝对不会承认是他们造成的。十分地气恼。上网一搜，发现早已有人和我有过同样的遭遇。不同的是，他们有人找月福理论了，月福果然不认账(与我意料的一致)。
下面是这两个文章的链接：
http://www.vehiclean.com.cn/link/gjsb.html
http://pop.pcpop.com/030602/462758.html
写在这里，大家办月福的洗车卡时，看着办吧。或者在他们擦车的时候多留意点儿，有问题当场指出也许会好些?没想到月福这么大的店，这么贵的收费，竟然会这样。郁闷那。

Effective C++

很多程序员对牛人们谈论编程经验和感想的书籍顶礼膜拜，例如市面上种种《xx缄言》，《xx夜里睡不着觉》，《高质量xx》，以及老外写的一些诸如《xx陷井与缺陷》，《Effective xx》，甚至还觉得不过瘾，又来个《More Effective xx》。不知道以后会不会再出《More and More Effective xx》，《More and More and More Effective xx》，然后一直就这样more下去，子子孙孙无穷匮。

出于好奇和对牛人以及伪牛人出书的敬佩，我也看过这些流行的小书。然后不由得想起有人曾对刘墉的文章的一句评价：“吃饱了饭，喝了杯凉水，然后放了个屁。” Bjarne Stroustrup是我心目中真的猛牛，在他的《The C++ Programming Language》一书第二版的序中，曾说过这样一句令我感动的话。 “这里的叙述仍然是针对有经验的程序员，并努力不去轻视他们的智慧和经验。” 作为一个自以为是的人，我希望得到这种尊重。

其实对于语言的学习，只要你仔细阅读语言的权威书籍，认真实践，并勤于和善于思考，很多xx的经验，不言自明。Bjarne说要写出一个好程序需要智慧、品位和耐性，万分赞同。关于如何避免在C++中依旧使用C风格，以及有效使用C++进行编程，Bjarne已经给出一些很好的忠告。胜似金玉良言。我想摘录出来，以供借鉴。其中interface一词，译者把它译为“界面”，而我觉得这里译为“接口”更妥当一些，便改为接口。另外在抄这些条目的时候，忍不住做了一点注释。

给C程序员的建议

一个人对C了解得越好，在写C++程序时大概就越难避免C的风格，并会因此丢掉某些潜在C++的优势。这里是几个有关的要点，在这些地方做同样的事情时，在C++里存在比C更好的方式：

［1］在C++里几乎不需要用宏。用const或enum定义明显的常量，用inline避免函数调用的额外开销，用template去刻画一族函数或者类型，用namespace去避免名字冲突。
（抄袭者注：宏使得代码不易于理解和维护，有更多潜在的陷井，增加了出错的可能性。这个建议在C语言中也有一定的适用性，并且gcc的扩展使得C语言也支持inline。）

［2］不要在你需要变量之前去声明它，以保证你能立即对它进行初始化。声明可以出现在能出现语句的所有位置上，可以出现在for语句的初始化部分，也可以出现在条件中。
（抄袭者注：在使用前定义变量而不是先定义好要用的所有变量再开始操作语句，这样使得代码可读性更好，并且不容易出错。在C中，对ANSI标准支持不好的C编译器，不允许在一个代码块中已经开始执行语句的位置定义变量。但如果编译器支持，那么在C语言中也应当采用这个建议。）

［3］不要用malloc（）。new运算符能将同样的事情做得更好。对于realloc（），请试一试vector（）。
（抄袭者注：new比malloc更加灵活，表达能力更强。使用new的代码常常更加简短，并且避免了“强制”这样的不良风格。）

［4］试着去避免void*、指针算术、联合和强制，除了在某些函数或类实现的深层之外。在大部分情况下，强制都是设计错误的指示器。如果你必须使用某个显示的类型转换，请设法去用一个“新的强制”，设法写出一个描述你想做的事情的更精确的语句。

［5］尽量少用数组和C风格的字符串。与传统的C风格相比，使用C++标准库string和vector常常可以简化程序设计。
（抄袭者注：C++在语言级别上提供了进一步的抽象，使得程序设计更加简化，维护更加容易。但无论使用C还是C++，使用安全而高效的库，总是比自己编写相关算法更好。因为这样不仅提高了生产效率，提高了代码的复用程度，而且使程序代码更简短，易于维护。所以尽量使用标准库中的容器和泛型算法，而不是自己处理低层的实现。即使自己可以将代码编写得和标准库一样高效和安全。）

最重要的是，试着将程序考虑为一组由类和对象表示的相互作用的概念，而不是一堆数据结构和一些去拨弄数据结构中二进制位的函数。


使用C++的一些忠告

要写出一个好程序需要智慧、品位和耐性。你不会第一次就能把它搞好的。试验！

［1］在编程序的时，你是在为你针对某个问题的解决方案中的思想建立起一种具体表示。让程序的结构尽可能地直接反映这些思想：
［a］如果你能把“它”看成一个独立的概念，就把它做成一个类。
［b］如果你能吧“它”看成一个独立的实体，就把它做成某个类的一个对象。
［c］如果两个类有共同的接口，将此接口做成一个抽象类。
［d］如果两个类的实现有某些显著的共同东西，将这些共性做成一个基类。
［e］如果一个类是一种对象的容器，将它做成一个模板。
［f］如果一个函数实现对某容器的一个算法，将它实现为对一族容器可用的模板函数。
［g］如果一组类、模板等互相之间有逻辑关系，将它们放进一个名字空间里。

［2］在你定义一个并不是实现某个像矩阵或复数这样的数学对象的类时，或者定义一个低层的类型如链接表的时候：
［a］不要使用全局数据（使用成员）。
［b］不要使用全局函数。
［c］不要使用公用数据成员。
［d］不要使用友元，除非为了避免［a］或［c］。
［e］不要在一个类里面放“类型域”;采用虚函数。
［f］不要使用在线函数，除非作为效果显著的优化。

请记住，这些忠告只是粗略的实用规则，而不是万古不变的定律。它们只应使用在“合理的地方”。从来就没有任何东西能够替代智慧、经验、常识和好的鉴赏力。

莫扎特密码

我一直觉得商业炒作情有可原，但对炒作艺术却万分反感。

这些日子晚上一换到CCTV-3就看到莫扎特密码这个节目。看到很多演奏的片断，极为美妙。节目中也常常播放一些景色，还有对一些外国人的采访片断。本来觉得挺好。可惜的是一看到标语，一听到主持人和嘉宾的评论，我就由衷地感到恶心。

与浪漫乐派的贝多芬，柴可夫斯基，肖邦，李斯特等人相比，我一直觉得莫扎特的音乐，虽然充满想像力和创造力，巧妙而优美，但没有起伏的情绪和锐利的思想。并且认为古典乐派的这些人的贵族音乐实在没什么意思。虽然贝多芬早期的作品也被列为古典时期的东西。

我喜欢的音乐家都集中在浪漫乐派。当然也有少数几位不是。比如巴洛克时期的维瓦尔第，充满了变幻和美妙的韵律。民族乐派的德沃夏克和格里格，无比地动人。尽管世人都狂赞莫扎特和海顿，我也觉得他们的一些作品很奇妙，但实在不觉得他们的音乐有什么过分的动人之处。当然这可能和我个人喜好有关。别人喜欢他们，自有他们的原因。但看到电视节目中对他们奇烂无比的评论，出于收视率或其他什么原因的炒作行径，我实在觉得是对音乐的一种玷污。

虽然有学识和见识的人通常不会当电视节目主持人，也不经常作为电视节目可笑的爪牙。但很难想像，一堆不懂音乐且没有思想的傻货，出于某种滑稽的原因竭尽他们低俗的文字能力评论一个音乐家。甚至把一个音乐人和密码学的名词扯到一起，让两者尽情地相互颠覆和嘲讽。实在是一种文化悲剧。

Java和Python

不得不承认，我一直对解释型的计算机程序设计语言心存偏见。
直到亲眼看到很多牛人从C++阵营转投Java阵营，直到亲眼看到很多应用程序用Java和Python开发，生产效率大幅度提高。直到最近因项目要求而亲自体会到Java的强大，直到今天知道Java也可以不那么慢，甚至可以不靠解释执行。

由于喜欢系统程序，崇尚实时控制，所以一直把软件的性能看得很重。虽然我也知道，最好的解决方案，不一定是最快的。若非系统软件，可以牺牲性能来获得更好的生产效率。很多场合使用Java，并不图它的可移植性，而是为了更高的生产效率。日益壮大的程序库，良好的错误处理和安全特性，使得Java的开发效率和C/C++相比成倍提高。抛开B/S应用不谈，开发同样的应用程序，Java可能比C++容易实现。

Java解释执行确实很慢，但运行慢，是有办法解决的。从《Java编程思想》中得知了几个方法，顺手用Google搜索了一下，找到以下信息。通过JIT，Native code，或Sun推出的HotSpot技术提高Java程序的执行速度。在不要求应用程序可移植的情况下，我觉得native code是个不错的选择。这样编译后的Java程序，失去了移植性，却获得了接近C++程序的运行速度。

http://www.trl.ibm.com/projects/jit/index_e.htm
http://disordered.org/Java-JIT.html
why_native
java_native_code
http://java.sun.com/javase/technologies/hotspot

比Java更加方便，语言本身的演化也更快的Python，被人们认为是更适合编程的动态语言。
也列出几个Python的资源。
http://www.python.org/
http://docs.python.org/
http://python.cn/
python_doc_cn

Update:

经过一番将Java编译为native code的尝试，认为以下几个工具不错。

gcj(http://gcc.gnu.org/java/):
ubuntu默认安装了，但gcj不支持swt，awt等图形库。

JNC(http://jnc.mtsystems.ch/):
不是完全免费的，但支持awt/swing，似乎也支持swt。但功能依然很简陋。

Excelsior JET(http://www.excelsior-usa.com/jet.html):
支持swt，awt，IDE式的图形化集成环境，操作便利。有Linux版本和Windows版本。
可惜是商业软件，并且十分贵(1200-5000美金)，但可以免费试用30-90天。
我试图用它编译巨慢无比的LumaQQ，出错了。
报告bug给该公司，他们说已经重现了问题，解决后会与我联系。
之后经过反复交流，他们修正了bug，态度非常积极热情。尽管我没有买他们的产品。
编译后的LumaQQ，使用JET的打包程序，可以安装到其他机器上使用。
不太满意的一点是，速度虽然比解释执行快了，但幅度似乎不大。
另外打包的时候，会把一个很大的JET的Runtime也一并打包进去，否则无法运行。
另外，试用版的JET会在LumaQQ退出的时候，显示一个关于版权的警告信息。
不过就功能而言，JET比前面两个工具要好很多。

找到一份关于解释型语言与C语言开发效率对比的文章：
动态语言开发效能的一个案例研究

另外听说Ruby on Rails可能与J2EE并存，成为Web开发的新模式。
很是激动人心。

荒谬的足球

PS: 这是旧博客上的一个文章，现在看来依然觉得骂得甚爽，就破例转到新博客中。

查看以前贴出那些文章的日期，发现我竟是以月为周期来更新blog的。这多少令我对自身行动的懒惰感到有些惭愧。我想，一个勤劳善良的人就是这样被岁月和生活摧毁的。那么，作为自由与反传统恶势力斗士的我，又能如何。

世界杯的喧闹终于平息，在它作乱的日子里，人们不厌其烦地到处议论这个竞技型的体育活动。偶尔会有人问我看昨晚的比赛了没，我就用极诧异的不解的神情望着对方，说一个低级的野蛮的活动，看它做什么。

其实我也是一个喜欢看足球的人。那是一个颇为休闲和惬意的节目。在我不能入睡的漫漫长夜，就打开电视，换到一个足球节目，将音量调到我能模糊听见的地步。 然后舒适地，惬意地，逐渐入睡。有时候完全的安静并不能抚慰人，使人安然入睡。有一些轻微的，舒缓的声音，就让人感到舒适和渴睡。足球节目和韩国电视剧就 能发出这样的声音。所以我难以言表我对足球节目的喜爱，因为它对改善睡眠有如此美妙的功效。但如果将生活中最大的激情都投入到一个体育节目上，就无疑是荒谬的了。

不理解很多人为什么明明自己也不会踢球，也不爱踢球，但却如此热衷于一个本不该这样火热的运动。他们的无知与从众，让一些仅仅是会踢个皮球而已的莽夫们 大红大紫。说他们是莽夫，绝无诋毁侮辱之意，而是纯粹客观地给他们一个公正的定位。每当看见他们因为把一个皮球踢到了球门里而欢呼雀跃，并一边奔跑一边向 观众挥指头致意，显露出无比自豪和得意的笑容时，我就觉得万分搞笑。这个时候亿万观众，甚至包括足球节目解说员，统统很失态地吼叫起来。还有比这更可笑的 事么？

会踢个皮球而已，至于如此地么？我也会踢，他们可能是比我踢得好一些而已，天天什么也不干就练这个么，踢得好一些也没什么稀奇的。这就像我会放屁，突然有 一个屁放得很动听，于是大家纷纷挤上来赞扬我。我就从此开始苦练放屁，力求将屁放得曲折迂回，婉转动听。就这样，我走红了。别人因为羡慕我走红，就也干起 这个来。然后我们就开始比赛，看谁的屁放得更好听。从业人员多了，就组织了很多放屁俱乐部。有很多商人赞助，有很多媒体关注和播放我们的比赛。亿万观众崇 拜和拥戴我们，纷纷效仿，狂热观看和议论我们的赛事。就这样，人们不再看球，开始看我们放屁。这看似滑稽，但本质上和当今之足球是一回事。

将一个强身健体和娱乐的体育活动，扭曲成一个政治相关，经济相关的，牟利的，黑暗与恶俗的活动，这有什么意思么？有必要如此狂热地喜爱么？被人类扭曲了的体育，就不再是真正的体育，就沦丧了体育原本的意义。