SHELL> echo "%3A%22abc%22" | perl -MURI::Escape -ne 'print uri_unescape($_)'
:"abc"

看來某程式碰到非 ASCII 字元就會爛掉。

工程師 A：「B 你能不能來幫我看看，為甚麼 configure 不過。」

工程師 B 仔細地看了一下螢幕上的 error messages，發現是因為找不到 crt1.o。

工程師 B：「看起來像是 libc 沒有裝，我們可以試著編一個 hello world 來確認。」

於是工程師 A 寫了一個 hello.c 如下：

#include <stdio.h>

int main()
{
    printf("Hello World\n");
    return 0;
}

用 gcc 編譯，gcc 會動，但跑出錯誤訊息，說找不到 stdio.h。

工程師 B：「果然。」

工程師 A 順手打了一下指令：

SHELL> locate stdio.h
Not found.

工程師 A：「Ubuntu 應該是用 apt-get 安裝軟體吧？」

工程師 A 試著下指令：

SHELL> sudo apt-get install libc
Cannot find package libc

工程師 B：「可能是叫做 glibc。」

工程師 A 試著再下指令：

SHELL> sudo apt-get install glibc
Cannot find package glibc

工程師 A：「見鬼了，誰知道 libc 應該要叫什麼啊！要怎麼知道套件的名字是什麼？」

工程師 A 試著打下面的指令：

SHELL> apt-get search libc
Invalid command 'search'.

工程師 B：「還是用 GUI 工具好了，至少應該會有個搜尋框可以用。」

工程師 A 從系統選單裡找到 synaptic 這支程式，查了幾次， 用 glibc 找不到任何東西，後來改用 libc 當關鍵字找，終於找到 libc6-dev 這個套件。

實在無法理解，為什麼 apt-get 沒有提供搜尋的功能，誰知道到底套件叫做 libc、glibc 還是 libc6-dev 啊。後來我知道，似乎搜尋的指令下法是 apt-cache search，可是 cache 這個字眼，跟 search 感覺上就是沾不到邊，真是莫名其妙的組合。其實我覺得，apt-get 的 get 也很莫名其妙，感覺上就是功能越做越多，沒有一開始就設計完善，最後只好通通塞在一起。

用 synaptic 的過程也是挫折感十足。利用其搜尋功能，確實地找到了 libc6-dev 這個套件，可是勾選安裝後，就不曉得接下來要怎麼辦，才能真的開始安裝。樸素的視窗，兩個人硬是 try 了十分鐘，才終於明瞭，要按工具列的「Apply」按鈕，才能開始安裝。誰知道這個 Apply 是在 apply 什麼啊，難道不能用個「Start」或「Next」的按鈕嗎？又不是在搞 version control，還要下個 commit 才會真正改變 repository。

最後，總算成功地編譯了 hello world，花了半小時。XD

然後我還是不懂，為什麼預設裝好有 gcc 但沒有 libc 跟標準 C 的 include files 可以用。要嘛就通通不要有開發工具，要嘛就基本的要裝齊全。不是每個人都是 kernel developer 好嗎？

後記：後來我們又發現，從頭到尾，我們是在 live cd 上工作，而不是在真正已經安裝在硬碟裡的 ubuntu 裡工作。難怪網路怎麼設都不會通。-.-||

這通常用於，如 mutex 這種，其實不屬於概念上的物件內容，但又需要存在於物件裡以維持正確運作的那些 member data。可是，這種「不屬於概念上的物件內容，但又需要存在於物件裡的」member data，該怎麼擺放於物件裡？

於是，在 #cpp-tw 裡，有了這樣的討論：

11:38 <jeffhung> 假設我們有一個 mutable mutex 的 member data，要放在 class 裡最前面，還是
                 最後面？
11:39 <jeffhung> 放最後面的好處是，這些 mutable 的 member，在轉成 persistent form 時，可
                 以直接 memcpy 然後把尾巴的 mutable members 去掉。
11:40 <jeffhung> 放最前面的好處是，sub object 的 construct order 是按順序來的，所以可以保
                 證 mutex object 比其他 member 還要早 construct，還要 晚 destruct。
11:40 <jeffhung> 這樣甚至可以在 initialization-list 裡 lock mutex。 (but how?!)
11:43 <jeffhung> (另一個擺法是，把 mutex 放在 parent)
11:43 <l*>       或者放在外頭.... ? XD
11:43 <l*>       (use a key-value table to store that....?)
11:44 <jeffhung> l*: 那這個 key-value table 可能也要 lock，會產生 bottleneck

目前我傾向於擺在前頭。我認為，物件內容的正確性，是第一要務，使用方便與否，則在其次。但關於這個議題，可能還有還沒考慮到的地方，因此也暫時沒有定論。諸位覺得呢？

warning: 'Foo' has a field 'Foo::impl_' whose type uses the anonymous namespace.

原來是因為，我在 foo.hpp 這個 header 檔裡，寫了一個 anonymous namespace，如下：

#ifndef FOO_HPP_INCLUDED
#define FOO_HPP_INCLUDED

namespace { // anonymous, so only library implementer know how to use it
    class FooImpl { ... };
}

class Foo
{
public:
    ...
private:
    FooImpl impl_;
};

#endif /* FOO_HPP_INCLUDED */

因為還沒有引入如 boost::shard_ptr<> 的機制，考量到 exception/thread safety，不想要讓 impl_ 是個指標，因此利用 anonymous namespace 的方式，把 FooImpl「藏」起來。不過，這樣的寫法，有潛在的問題，因此 gcc 發出 warning 警告。

Compiler 在編譯時 anonymous namespace 時，相當於以 compilation unit 為單位，為裡面的 anonymous namespace，取一個獨一無二的名字，然後自動 using 之。若 header 檔被不同的 source 檔引入，成為不同的 compilation unit，則 anonymous namespace 所自動產生的名字，皆不相同，共同運作時，就會產生問題。

以上例來說，foo.hpp 可能被 a.cpp 與 b.cpp 分別引入，兩者分別建構了 Foo 類別的物件，依據以上說明，a.cpp 裡面的 Foo 類別的物件，其 impl_ 成員的型別，可能是 anonymous_a；而 b.cpp 裡面的 Foo 類別的物件，其 impl_ 成員的型別，則可能是 anonymous_b。同樣是 Foo 類別的物件，在不同的 compilation unit 裡，其 impl_ 成員，型別卻不同，這個歧異，肯定會造成問題。

因此，我們應該避免在 header 檔，使用 anonymous namespace。

可是，若不能在 header 裡使用 anonymous namespace 的話，那 anonymous namespace 到底有甚麼存在的意義呢？畢竟，我們大可以直接在 source 檔裡宣告類別，反正其他 source 也看不到，不就有了 anonymous namespace 的效果了嗎？

其實，anonymous namespace 還是有其存在意義的，畢竟，anonymous namespace 依然是一個 namespace，而 namespace 的作用，就在於避免 name collision。好比說，我們永遠無法保證，source 檔所引入的其他程式庫的 header 檔，在未來版本裡，會不會冒出一個，名字跟我們想要藏起來自己用的類別、函式或變數。而有了 anonymous namespace，我們就可以保證，此時不會發生 name collision。

參考資料：

• comp.lang.c++.moderated » warning: ... has a field ... whose type uses the anonymous namespace

The most complex part of Test::Continuous is to detect whether we should build and test, or just waiting for source file changes. I'm not sure how gugod did that in Perl, but this is absolutely what make(1) good at. The -q argument for GNU make will return an exit status indicating whether specified targets are already up to date or not. So we may write an infinite loop and ask GNU make to check whether depended source is changed or not, and really do the build/test if make -q returns nonzero.

And, with the help of gnome-cli-notify.py, it is easy to show a notification popup when build/test failed or vice versa.

So, here comes the script. Enjoy.

#!/usr/bin/env bash
# ---------------------------------------------------------------------------
# Amarganth Development Environment
# Copyright (c) 2007, Jeff Hung
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
#  - Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#  - Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#  - Neither the name of the copyright holders nor the names of its
#    contributors may be used to endorse or promote products derived
#    from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# ---------------------------------------------------------------------------
# $Date: 2009-07-27 10:18:22 +0800 (Mon, 27 Jul 2009) $
# $Rev: 489 $
# $Author: jeffhung $
# ----------------------------------------------------------------------------
# revid: "@(#) $Id: scm.old 489 2009-07-27 02:18:22Z jeffhung $"
# ----------------------------------------------------------------------------

__exe_name__=`basename $0`;
__revision__=`echo '$Rev: 560 $' | cut -d' ' -f2`;
__rev_date__=`echo '$Date: 2007-07-19 11:07:45 +0800 (星期四, 19 七月 2007) $' | cut -d' ' -f2`;

continuous_timeout=5
error_stop_timeout=30

if [ $# -lt 3 ]; then
    echo "\
Usage: continuous-test <build-target> <test-target> <notify-cmd> ...

The continuous-test script make(1) your <test-target> continuously while we
developing.  The script repeatedly asking GNU make(1) to determine whether
<build-target> need to be built or not.  If it needs to be built, build it
and then <test-target>.  If any of <build-target> or <test-target> failed,
run <notify-cmd> to notify we developer.  If build successed, <build-target>
no longer need to be built, and this script go back to check continuously.

This script requires GNU make(1) and bash(1).

Example:

  $ continuous-test all test \\
    \"gnome-cli-notify.py 'Test Failed...' 'Check error console please.'\" \\
    ;

Revision: r$__revision__ ($__rev_date__)";
    exit;
fi;
build_target="$1"; shift;
test_target="$1"; shift;
notify_cmd="$1"; shift;
while [ $# -gt 0 ]; do
    notify_cmd="$notify_cmd '$1'";
    shift;
done;
#echo "$notify_cmd";

while [ -z '' ]; do
    make -q "$build_target";
    if [ $? -ne 0 ]; then
        echo "Change detected, build and test!!";
        rm -f "$temp_file";
        make "$build_target" && make "$test_target";
        if [ $? -ne 0 ]; then
            echo ">>> TEST FAILED!!";
            if [ -n "$notify_cmd" ]; then
                eval $notify_cmd;
            fi;
            read -n 1 -t $error_stop_timeout \
                 -p "(`date '+%H:%M:%S'`+$error_stop_timeout) Stop continuous test (y/N)? " \
                 ans;
#           if [ \( $? -ne 0 \) -o \( "$ans" = 'y' \) ]; then
            if [ \( $? -eq 0 \) -a \( "$ans" = 'y' \) ]; then
                echo;
                break; # while
            fi;
        fi;
    fi;
    printf "\r";
    read -n 1 -t $continuous_timeout \
         -p "(`date '+%H:%M:%S'`+$continuous_timeout) Stop continuous test (y/N)? " \
         ans;
    if [ \( $? -eq 0 \) -a \( "$ans" = 'y' \) ]; then
        echo;
        break; # while
    fi;
done;
echo 'End.';

This script is written in Bash for the read builtin, cooperate with GNU make.

版號後綴字

Windows SDK API 裡有個奇怪的命名慣例 (naming convention)，學過 Windows Programming 應該都耳熟能詳：API 的加強版，通常是在原來的名字後面，加上個 Ex 後綴字尾以命名之。例如，CreateWindow() 的加強版，就叫做 CreateWindowEx()。

之所以說這種命名慣例會「奇怪」是因為，如果還要對 Ex 版增強的時候，該怎麼辦？難道還要來一個 CreateWindowExEx() 嗎？那豈不沒完沒了？

針對這種問題，常見的解法有兩種。第一種比較簡單，就是棄 Ex 改數字。例如 sqlite3_open() 與 sqlite3_open_v2() 和 xmlrpc_client_init() 與 xmlrpc_client_init2()。SQLite 的命名法比較囉唆，可是應該是因為還要支援 UTF-16 版的緣故；xmlrpc-c 的方法比較常見，個人認為也比較簡潔方便。

型別後綴字

除了利用後綴字來表明版號之外，有時候，函式名稱後綴字也用來表明，其所處理的資料型別。舉例來說，Microsoft 的 generic-text-mapping 技術，利用 A 或 W 後綴，來區分輸出入使用 char 或 wchar_t 型別。

前述提到 sqlite3_open() 有 UTF-16 版本，命名為 sqlite3_open16()，也是類似的手法。

我個人覺得，這種後綴字還算可以接受，可是如果是在用 C++，那就很搞笑了。事實上，若有機會用 C++ 把這類 C 的 API 包裝起來的話，我都會利用 overloading 機制，把型別後綴字幹掉，圖個清爽。

行為後綴字

另一種常見的 API 後綴字，代表著函式的行為不太一樣。例如很多 non-thread-safe 的 API，其 reentrant 版，也就是可安全地重複使用的版本，會在名稱後面加上 _r 的後綴字。例如 strtok() 的 reentrant 版叫 strtok_r()。通常加上 _r 的 API，其參數都會不太一樣，否則直接解掉問題即可，沒必要再另外發明一個 API。

Microsoft 在 Visual C++ 裡，對這類 non-thread-safe 的 API，解法不太一樣。使用 multithread 版 run-time library 時，若要從 non-thread-safe 變成 thread-safe 時，參數可以一樣不變，則同上述直接改掉實作，解掉問題，API 不變。可是，當碰到需要修改 prototype 更動參數時，Microsoft 用的是骯髒的手段，如利用 TLS 儲存需要增加的參數，使得 API 還是不變。原本因呼叫了 non-thread-safe API 的程式，立地成佛變成 thread-safe。

這其實會產生一些問題，妨礙 porting 我認為問題還小，讓 programmer 自以為安全，才是真正的隱憂。我認為，Microsoft 應該要做的，其實是當使用 multithread 版 run-time library 時，像 security enhanced crt 那樣，在 compile 時產生 deprecation warning，建議使用 reentrant 版 API 才對。

講到 VC 的 security enhanced crt 就好笑，Microsoft 會在有安全疑慮的 API 後面，加上個 _s 後綴字。但問題是，M$ 根本沒有在管，參數是否相同，只要有安全疑慮，即使參數相同，也會發明一個對應的 _s 版 API。若目的是為了讓 programmer 可以認知道其實這個 API 並不安全，那就很搞笑了，參數相同時，讓 API 實作能夠安全，不正是 vendor 的責任嗎？更別提，實際上 _s 版 API，並沒有多安全的問題了。

隨便亂選後綴字

講了這麼多，其實我是想碎碎念，新同事你實作 thread-safe 版 API，在後面加上 _s 後綴字是想怎樣？畫虎不成反類犬，真是厲害。

還好我不再需要面對這種隨便亂選後綴字的 API 了。阿彌陀佛，善哉，善哉。

我們需要讓使用的 libcurl 支援 SSL，目標是要讓後續的開發，只在 IDE 進行即可，必須要做到從 repository 裡 checkout 出來，只要打開 IDE 就可以做完所有的事。

原本 curl 的 source tarball 裡，有包含了 lib/curllib.dsp 這個 VC6 的 project 檔，但很可惜的，這是給 newbie 用的，所以不包含 3rd-party 組件，如 OpenSSL。見 docs/INSTALL 檔：

Intentionally, these reference VC++ 6.0 projects and configurations don't use third party libraries, such as OpenSSL or Zlib, to allow proper compilation and configuration for all new users without further requirements.

但是我們已經使用這個 curllib.dsp 建立好了 for IDE 的開發環境，所以必須想辦法，把「老鳥的手段」放進「菜鳥的籃子」裡。

為了少編譯一個 OpenSSL 套件，我選擇使用 GnuWin32 預先編譯好的 native openssl package，抓下安裝程式，安裝到預設的目錄即可。

OpenSSL 共有兩個 DLL 檔：libeay32.dll 與 libssl32.dll。可是，GnuWin32 這個預先編譯好的套件，雖然說包含了 development files，但沒有包含 VC6 用的 DLL import library 或 def 檔，所以必須自己生出來。

一開始我先試著從 GnuWin32 版 OpenSSL 的 source tarball (openssl-0.9.8h-1-src.zip)，解出裡面的 libeay32.def 與 ssleay32.def，以製作對應的 import libraries：

SHELL> RENAME ssleay32.def libssl32.def
SHELL> "C:\Program Files\Microsoft VisualStudio\VC98\Bin\VCVARS32.BAT"
SHELL> LIB /DEF:libeay32.def
SHELL> LIB /DEF:libssl32.def

其中，ssleay32.def 其實是 libssl32.dll 對應的 DEF 檔，故先正名之。然後引入 VC6 開發環境，呼叫 LIB.exe 工具，從 DEF 檔做出 import libraries。

測試結果發現，程式一啟動，就跳出視窗抱怨，找不到 libeay32.dll 序號 968 的 API。用 depends.exe 查，ordinal 968 這個 API 根本就是 N/A，從 libeay32.def 裡也找不到編號 968。

所以只好自己來，利用 DUMPBIN.exe 工具，直接從 DLL 裡列出 exported symbols，如下：

SHELL> DUMPBIN /EXPORTS libeay32.dll > libeay32.def
SHELL> DUMPBIN /EXPORTS libssl32.dl

然後編輯這兩個 .DEF 檔，把無關的東西去掉，僅剩下 exported symbols，弄成下面這個樣子：

EXPORTS
        symbol1
        symbol2
        ...

從第二行開始，使用 TAB 字元縮排。

然後重複上面的程序，利用 LIB.exe 工具，製作出 import libraries，這次就可以正常使用了。把產生的 .def、.lib 與 .exp 檔，放到 %ProgramFiles%\GnuWin32\lib 目錄下，把兩個 DLL，放到 %ProgramFiles%\GnuWin32\bin 目錄下，然後如下修改 curllib.dsp 的 project setting，即可正常編譯出具備 SSL 功能的 libcurl：

• Add preprocessor definition: USE_SSLEAY；
• Add include directories: %ProgramFiles%\GnuWin32\include 與 %ProgramFiles%\GnuWin32\include\openssl；
• Add additional library path: %ProgramFiles%\GnuWin32\lib；
• Add additional libraries: libeay32.lib 與 libssl32.lib。

不過，要正常使用 SSL 功能，還是必須想辦法搞到 CA 給 curl 用才行。目前最新的 curl 版本，已經不再內附 CA certifications 了，所以我們要自己生才行。查 curl 文件，我們需要 PEM 格式的 CA。本來想說直接開 IE 或 firefox 把裡面用的 CA 匯出，可是發現沒辦法匯出成 PEM 格式。還好翻查 FreeBSD 裡灌的 curl，在 /usr/local/share/curl 目錄下，可以找到 curl-ca-bundle.crt 檔，將之如下傳給 CURLOPT_CAINFO 選項即可：

curl_easy_setopt(handle, CURLOPT_CAINFO, "/path/to/curl-ca-bundle.crt");

至此，大功告成。

參考資料：

• The Secret to cURL in PHP on Windows...

我習慣一個函式庫，會有一個 config.h，將所有 compile-time options 放在裡面，並規定函式庫裡的所有 header/source files 都一定要引入此 config.h，這樣子裡面的設定，才能廣為周知。

假設這個函式庫叫 messy，則 config.h 會位於 include/messy/config.h，平常以 #include <messy/config.h> 引入。那我們可以用以下的 perl 程式片段，檢查是否每個 header/source files 皆有引入 config.h：

use File::Grep;
use File::Find::Rule;

print "CHECK: C/C++ sources must include <messy/config.h>.\n";
print join(
    "\n",
    map { "| $_->{'filename'}" }
    grep { $_->{'count'} == 0 }
    File::Grep::fgrep { /^\s*#\s*include\s+<messy\/config.h>/ }
    grep { $_ !~ m/messy\/config.h$/o }
    File::Find::Rule->or(
        File::Find::Rule->directory->name('.svn')->prune->discard,
        File::Find::Rule->file()->name(qr/\.(h|hpp|c|cpp)$/i)
    )->in('include', 'src')
) || "[ok]";
print "\n\n";

把這段程式，放在 post-build 裡，每次編譯函式庫時，最後就會執行，檢查除了 include/messy/config.h 以外的所有 header/source 檔案，是否皆有引入 include/messy/config.h，沒有引入的檔名，就會列出來，若統統都有引入，就會印出 [ok] 字樣。如下：

CHECK: C/C++ sources must include <messy/config.h>.
| include/messy/debug_tool/func_trace.hpp
| src/messy.debug_tool.func_trace.cpp

修正後就會變成如下：

CHECK: C/C++ sources must include <messy/config.h>.
[ok]

檢查結果會一併出現在 build log 的最後面，有需要時，就可以依據指定的「慣例」，去修正那些有問題的檔案。

因為工作氛圍之故，無法擺脫 Visual C++ IDE 那一套 build configuration 機制，所以只好寫了這一個 vc-build.bat 的批次檔，直接在 console mode 下進行原本要按按鈕、點選單，才能做的事。

程式碼在此：vc-build.bat on github，使用起來很簡單：

------------------------------------------------------------------------------
Usage: vc-build.bat [vc] [solution] [project] [configuration]
Usage: vc-build.bat [vc] [solution] [project] [configuration] [action]
------------------------------------------------------------------------------
            [vc] could be vc6, vc8, or vc9.
      [solution] is the .dsw or .sln file.
       [project] is the project to build.
 [configuration] could be Debug or Release, normally.
        [action] could be BUILD, REBUILD, or CLEAN (case insentively).

依據以上的參數說明，執行即可。包括於 project 檔裡設定好的 pre/post events 的外部程式，都會正確執行。除了可以與 buildbot 這類 continuous integration 工具整合之外，設定進 vim 的 makeprg 參數，亦是擺脫 IDE 的好方法。

參考資料：

• Incredibuild 在 console 模式 build project 的語法
• MSDN - Devenv Command Line Switches

轉成 DocBook 格式有很多好處，除了是一種 wordpress independent 備份方式外，亦可以再輸出成 PDF、Word 等做更進一步的處理。有時候要把文章給別人的時候，不方便直接把網頁印下來，若有 DocBook 版，就可以先轉成 word，再修補一下就搞定了。

這個 wp2docbook.pl，讀入 wordpress export 後，會試著理解文章裡的 HTML 碼，轉換成對應的 DocBook 標籤。可以輸出成一個超級大 DocBook 檔，裡面有很多 <article>，也可以每一個 <article> 輸出一個檔，方便備份整理。我用自己的 blog 測試過，六百多篇文章，沒什麼問題。

不過那是在那個時候。XD

如同 gslin 所述，wordpress 的 export 檔，格式問題很多。在寫 wp2docbook.pl 的時候，就搞了很多 hacks，試著解決格式問題。這些 hacks 雖然沒有像 gslin 那樣暴力，但也差不多了。最後發現，export 檔格式一直在變，隨著版本更新，有的欄位修好了，有的欄位又爛了。後來覺得，跟著 wordpress 一直修修補補轉檔程式，實在很沒意思，就放棄更新了。

本來那時就要撰文記錄之，但標題有了就擺在 draft 好久。現在既然提到了，那就釋出吧，順便練練 git 與 github 的使用。這個版本已經不能處理目前最新的 wordpress 2.7.1 版的 export 檔了，不過以 BSDL 釋出，有需要的人就自己再 hack 吧。

請享用：wp2docbook on github。

不過我還是不習慣 VB/wxWidgtes 的字串處理風格，感覺上太沒有效率了，邊寫就會邊想，這如果是在 C/C++，可以怎樣寫，效率可以好上多少倍。

所以我還是直接用 std::string 寫好了，字串處理完畢，再轉成 wxString 送回去。

實際上，用 MFC 的 CString 也是一整個彆扭，個人感覺甚至比 VB 的字串、wxString 還要來的更糟。

哼哼，一切都是註解太多的錯。

另一個錯的是 Windows Programming 的 style，要不是已經把 error handling 另外濃縮處理過了，否則不含註解的部份，還要再膨脹個 5 倍左右。

在工作上，有時候會聽到這樣的怒吼：「吼～又是你的 assertion 把程式當掉。」可是，細查之後卻又發現，之所以會 assertion failure，是某個應該存在的值不存在，或某件事情在之前就失敗了，於是當程式執行到 assertion 處，一檢查就發現問題，然後把程式當掉。

Assertion 之所以存在，為的就是希望能夠揪出，所有不應該存在的異常情形，是故，assertion 其實應該是多多益善，埋的越多，越有機會揪出程式的不良之處。所以，我很喜歡埋 assertion，凡是無法處理的特殊輸入、必須存在的情境參數，甚至是失敗就等於整個程式根本無法運作的 API 呼叫，我都會使用 assertion 以便盡早地把程式當掉，輔助我們揪出錯誤的發生點。

問題是，當 assertion 發生時，總是要有某個人負責去找出問題的成因，而理所當然地，在只有 assertion failure 這條線索的情況下，問題就被丟給寫 assertion 的人。但因為 assertion 通常是用來抓「不是在此處發生的錯誤」，因此產生了這麼一個吊詭：

越認真地(寫程式)使錯誤顯現的人，反而越容易領到爛攤子，必須承擔解決(多半)不是其程式所造成之錯誤的責任。

一般來說，程式設計師比較喜歡寫新程式，而不喜歡維護舊程式，更討厭的就是負責維護不是他寫的舊程式，所以上述的吊詭，等於是在懲罰認真的人，而且是越認真(埋 assertion 炸彈)，等著的是越多的爛攤子。

也就是說，可以討論的，應該是 assertion 的標的是否合適，而不是 assertion 是否應該把程式當掉。只要標的合適，當程式當掉時，我們該慶幸，assertion 讓我們發現，程式會當掉，而不是等到移交給客戶後，隱藏的炸彈才一個一個爆發。

在經濟學裡，「邊際成本 (marginal cost)」指會隨著每單位生產的新產品而增加的成本，例如製作每個麵包，所需要之麵粉的購買成本。Wikipedia 如是說：

在經濟學和金融學中，邊際成本指的是每一單位新增生產的產品（或者購買的產品）帶來到總成本的增量。

與之相對的則是「固定成本 (fixed cost)」，不會隨著業務量而變化的成本，如烘培麵包所需之烤爐的購置成本。

而當在寫程式的時候，可能會碰到的 resource leak，其行為也可以分成兩大類：程式執行一次，不管做了多少事，固定會洩漏一定量的 leak，以及隨著做的事情越多，洩漏的量越多的 leak。

套用經濟學的概念，我在想，其實可以把上面這兩大類 resource leak，稱呼為：

• fixed leak：程式執行一次，不管做了多少事，固定會洩漏一定量的 leak；
• marginal leak：隨著做的事情越多，洩漏的量越多的 leak。

其中，marginal leak 較為嚴重，會隨著程式執行越久，吃掉越多的資源，最後導致資源不足，使程式當掉，甚至當掉整台電腦。

而 fixed leak 問題較小，若時程不夠，通常我們會忽略之。不過要小心的就是，若程式支援某種 reset 機制，如某些 server 收到 SIGHUP 會重讀設定檔，則可能某些 fixed leak 會現出真面目，其實是 marginal leak，會隨著 reset 而增加洩漏的量。

好奇，用加雙引號的 "marginal leak" 查了一下 google，發現只有 160 筆。區分這兩種 leak，一般都是用什麼專有名詞啊？

面對體無完膚，多個臟器破裂，到處都是還沒找到的破洞，在這個情況之下，這種內出血嚴重的程式模組，code review 已經沒有用了。

更別提原作者在會中，一直嚷嚷，看起來都沒問題啊。XD

2009-03-23 13:00 更新：補一下這篇《The only valid measurement of code quality: WTF/m》。

對應的 API 代換很簡單，例如 pthread_create() 換到 Win32 平台，可以用 _beginthreadex() 代替，頂多需要注意一下參數的不同即可。

有些 API 代換則比較複雜一些，牽涉到程式邏輯的不同。不過因為在功能面上是對等的，只是寫法不同，所以也不是什麼大問題。

例如，「列出目錄內容」這件事，在 UNIX 上要用 opendir/readdir/closedir 這組函式：

void list_dir(const char* dir)
{
    DIR* d = opendir(dir);
    dirent* e;
    while ((e = readdir(d)) != NULL) {
        printf("%s\n", e->d_name);
    }
    closedir(d);
}

但是到了 Windows 上，則要用 FindFirstFile/FindNextFile/FindClose 這組函式：

void list_dir(const char* dir)
{
    // prepare wildcard path
    char wild[MAX_PATH];
    strcpy(wild, dir);
    strcat(wild, "\\*");

    WIN32_FIND_DATA wfd;
    memset(&wfd, 0, sizeof(wfd));
    HANDLE h = FindFirstFile(wild, &wfd);
    if (h == INVALID_HANDLE_VALUE) {
        throw "FindFirstFile() failed.";
    }
    do {
        printf("%s\n", wfd.cFileName);
    } while (FindNextFile(h, &wfd));
    FindCloseFile(h);
}

兩組函式的寫法不太一樣，差別在於，第一筆資料在 UNIX 上，同其他筆資料，係由 readdir() 取得，但在 Windows 上，卻是第一筆資料由 FindFirstFile() 取得，其他筆資料由 FindNextFile() 取得。這點差異，導致了兩邊的程式寫法不太一樣。

不過如何，最近我碰到的這個例子，才真的叫難。

話說 socket programming 是由 BSD (UNIX) 發展出來的，之後才移植到各個平台，如 Windows 上的 WinSock。當一條 TCP 連線使用完畢時，我們可以呼叫 close() 將這個 socket 關閉，也可以用 shutdown() 取代 close()。

在 UNIX 裡，close() 會做 reference counting，若有多個 socket 對應到同一條 TCP connection，則只有當最後一個 socket 被 close() 時，這條 TCP connection 才真的會被結束掉。這通常發生於使用 fork() 來處理 incoming connection 時，母行程 accept() 得到 socket 後，會呼叫 fork() 複製出子行程來處理。此時，母行程與子行程各自擁有一個 socket，同時對應到這條 TCP connection。當母行程 fork() 完畢後，會馬上呼叫 close() 將 socket 關閉，因為母行程再也不需要用到這條 TCP connection。如果這個 close() 真的把 TCP connection 給結束掉，那子行程就沒戲唱了。所以，close() 會做 reference counting，只有在子行程也 close() 時，才會真的把 TCP connection 關閉。

在 Windows 裡，socket 不能用 close() 關閉，要用一個特別版本的 closesocket() 才行。closesocket() 與 UNIX 上的 close()，功能相同。

至此，porting 仍處在 API 對應的等級，很簡單。可是，問題就出在可以取代 close() 的 shutdown()。

兩者之間的差別在於，shutdown() 將不理會 socket 的 reference counting，馬上送出 FIN 將 TCP connection 結束。使用 shutdown() 的好處顯而易見，我們可以確定這個 TCP connection 立刻結束，可加強資源控管。

依據《UNIX Network Programming》這本 socket programming 的聖經級書本所述：

If we really want to send a FIN on a TCP connection, the shutdown function can be used instead of close.

我們可以用 shutdown() 完全取代 close()：用了 close() 就不要用 shutdown()，用了 shutdown() 就不要用 close()。

可是，MSDN 卻說：

The shutdown function does not close the socket. Any resource attached to the socket will not be freed until closesocket is invoked.

意思是說，在 WinSock 裡，用了 shutdown() 之後，還要用 closesocket()，才能「關乾淨」把資源全部釋放。

就是因為這一點細節的不同，若是忽略了，就會產生 leak。要不是不小心看到 MSDN 的這一句，我也會疏忽掉，產生極難追蹤的 bug。

唯有通曉這類精微的細節，才能做到「真㊣的 porting」。面對浩如瀚海的 Windows APIs，我也只能兢兢業業地，一步一腳印，細讀 MSDN 的每一字每一句，希望能夠捕捉到，這些會害死人不償命的微光掠影。

有趣的是 Feature Description：

The MySQL Embedded Server offers the MySQL-Server functionality in a small library that can be bundled with other applications.

This feature requires 151MB on your hard drive.

真是厲害，embedded server 要 151 MB，還說明是 a small library，不曉得是小到哪裡去了。

事情是這樣子的。在一組透過 HTTP 溝通的網路程式裡，其中一端把某個型別為 uint32_t 的參數，用 sprintf() 轉成文字形式，附在 URL 的 QUERY_STRING 裡，傳送到另一端，接收端收到後，從 URL 裡 parse 出文字形式的這個參數，丟給 atoi() 轉回 uint32_t。整個流程大概如下圖：

uint32_t ID = 0x9fffffff;              uint32_t ID = 0x7fffffff;
            |                                      ^
            |                                      |
sprintf(qstr, "%u", ID);                  atoi("2684354559");
            |                                      |
            v                                      |
       "2684354559"                          "2684354559"
            |                                      ^
            |                                      |
            +--(append to URL, pass via Internet)--+

問題出在 atoi() 這個函式，其回傳值是個 int。所以只要這個數字大於 INT_MAX，也就是 0x7FFFFFFF，就一定會回傳 0x7FFFFFFF。於是，這個數字就被改掉了，不正確的結果，導致程式其他部份行為不正常。

解法有兩種：使用 std::istringstream，或是 sscanf()，這兩個都可以反應型別的不同，只不過前者可以自動反應，後者需手動使用 "%u" 格式字串。

如果嫌這兩個方法，寫起來又臭又長，也可以使用 Boost 的 lexical_cast。不過這個一樣得寫明輸出型別為 uint32_t，但比 "%u" 好懂許多。不曉得在 C++0x 裡，可不可以利用 auto，寫成下面那樣，會比較方便：

ID = lexical_cast<auto>("2684354559");

如果 auto 能夠省去，那就更方便了。

在 MSDN 裡，CreateNamedPipe() 這個函式的第三個參數 dwPipeMode 的說明裡，有這麼一句話：

The functions fails if dwPipeMode specifies anything other than 0 or the flags listed in the following table.

我第一眼讀完的理解是：

The functions fails if dwPipeMode specifies ( anything other than 0 ) or ( the flags listed in the following table ) .

於是大驚小怪的叫：有沒有搞錯，寫 0 或者「沒有列在」下面表格的那些 flag，才不會失敗？！

兩分鐘後，仔細重讀才發現，原來是我斷句錯誤。這句應該是這麼被理解的：

The functions fails if dwPipeMode specifies anything other than ( 0 ) or ( the flags listed in the following table ) .

兩種斷句，應該都可以，只不過第一種很搞笑，第二種才合理。

習慣上，我在撰寫英文句子時，會儘量讓 "or" 兩邊的子句，長度差不多，感覺比較對稱。也許就是因為這種習慣，讓我把句子讀錯了吧。

在 thread function 裡用 catch (...) 攔截所有可能的例外

這是因為，thread function 的啟動，是透過系統完成，無法傳遞 exception，更因為 thread function 相當於 main() of thread，是 stack unwinding 的終點，如果不用 catch (...) 把「所有」可能的例外攔截下來，則視系統不同，輕則整個 process 結束，重則僅該 thread 無聲無息地消失，程式裡其他 thread 繼續執行，整個程式看起來沒什麼問題，但實際上卻有一個 thread 已經不見了，等到要發現問題，可能要在一個月以後。

最簡單的 thread function，應該這麼寫：

int thread_func(void* param)
{
    // nothing above try
    try {
        // do real job
    }
    catch (...) {
        // ellipsis to catch all possible exceptions
    }
    // nothing after catch
    return 0;
}

在 thread proxy 裡用 catch (...) 攔截所有可能的例外，並提供預設處理機制

同上面的理由，如果 thread library 是我們自己撰寫的，則通常會有個 thread proxy，library 把 thread proxy 傳給 OS，OS 啟動新的 thread 時，先執行 thread proxy，然後 thread proxy 才轉呼叫真正的 thread function。因為不同平台的 native thread function 的 prototype、calling convention 可能都不一樣，因此依據平台的不同，必須準備不同版本的 thread proxy，這樣才可以讓 thread function 的 prototype、calling convention 一致化。

因此，對於 OS 來說，這個 thread proxy 才是真正的 thread function，thread proxy 是第一線，原來的 thread function 是第二線。因為寫 library 是要給人用，有可能用的人沒有注意到前一點，忘記在 thread function 裡 catch (...)，還好我們還有更底層的 thread proxy，可以在此 catch (...) 並做一些處理，就可以避免意外發生。

例如 Boost.Thread 1.37.0 的 thread proxy 是這麼寫的：

void* thread_proxy(void* param)
{
    boost::detail::thread_data_ptr thread_info
        = static_cast<boost::detail::thread_data_base*>(param)->self;
    thread_info->self.reset();
    detail::set_current_thread_data(thread_info.get());
    try {
        thread_info->run();
    }
    catch(thread_interrupted const&) {
    }
    catch(...) {
        std::terminate();
    }

    detail::tls_destructor(thread_info.get());
    detail::set_current_thread_data(0);
    boost::lock_guard<boost::mutex> lock(thread_info->data_mutex);
    thread_info->done=true;
    thread_info->done_condition.notify_all();
    return 0;
}

Boost 選擇的處理方式，是呼叫 std::terminate()，把程式結束，這樣至少 thread 不會無聲無息地消失。