Doxygen documenting with Generic-Text-Mapping
在《Writing libraries with Generic-Text-Mapping》一文裡，我介紹了怎樣撰寫具備 generic-text-mapping 機制的 library。在該文文末，我提到了目前的缺憾是，沒辦法做出漂亮的 doxygen 文件。最近，我終於摸索出，如何使用 doxygen 做出如 MSDN 那般，能夠漂亮展現 generic-text-mapping 型函式的文件寫法。
Writing libraries with Generic-Text-Mapping
最近在設計某 library 的 API，所以就想順便來講講怎麼設計符合 generic-text-mapping 的 library。簡單講，generic-text-mapping 是一種利用 preprocessor 的技巧，用一個 define symbol 決定 application 程式裡用的 character，是指 char 亦或是 wchar_t。若是後者，就是我們常在說的 unicode 程式。
個人覺得 generic-text-mapping 實在是 Microsoft 當年偷懶後的結果。在那個年代，這個技術確實是讓眾多既存程式快速升級成 unicode 程式的好方法，但在 unicode 支援已經普遍成熟的現在，卻反而形成了脫褲子放屁的尷尬[1]。
言歸正傳。尷尬歸尷尬，畢竟我們寫的 library，還是不免需要在 Windows 上執行，讓其他 windows developer 使用，因此入境隨俗，從「惡」如流，還是必須的。如何呼叫使用了 generic-text-mapping 技術的 library，已經有太多文章闡述了[2]，因此以下簡述如何寫作 generic-text-mapping 的 library 供他人使用。
同時提供兩個版本，最後才用 macro 選擇
以下的範例程式，採用並擴充 Microsoft 的 convention，後綴字(postfix)為 W 時，表示是 wchar_t 的版本；後綴字為 A 時，表示是 ANSI[3]，即 char [...]
Reverse std::binary_function parameters
為了繼續寫某一篇自去年年中[1]開始寫，到現在還沒完工的文章，不得已，只好把其中一部分岔開來，另外開了這篇，以免太複雜。那篇文章之所以會拖這麼久，當然是因為斷斷續續地寫，以及其中的技術我尚未完全掌握的緣故啦。
言歸正傳，C++ 的 <functional> 的概念很好用，可是標準裡有提供的功能，實在是太少了，所以常常會發生，要兜卻兜不出來，只好退回去全部用迴圈重寫。碰到這樣的情形，又無法拋棄 C++ 的偏執的話，頗令人沮喪。所以有機會的話，最好還是自己把缺的東西刻一刻，累積下來，希望總有一天能夠快快樂樂用 C++，無憂無慮沒煩惱。
這裡介紹的 functor，正是最近為了那篇還沒寫完的文章而刻的一個 functor。設這個 functor 叫做 g，g 要做的事情很簡單，就是把要傳給另外一個 functor f 的兩個參數先對調之後，再傳給 f。也就是說，本來是 f(lhs, rhs) 這樣子呼叫，透過 g，變成 f(rhs, lhs) 的呼叫方式。
概念很簡單，所以實做起來也很簡單，其實作與 helper function 如下：
template <class Op>class param_reverser : public binary_function<typename Op::second_argument_type, [...]
Use numeric_limits<>::max() with while avoiding VC6 min/max macros
多年以前，Microsoft 幹了一件比 #define N 3 還要蠢的蠢事，那就是在 <windows.h> 放入了 min/max 這兩個 macros。因此，我們沒辦法好好地使用 C++ Standard 的 min/max 這兩個 algorithms，也沒有辦法好好地使用 numeric_limits<>。前者 Microsoft 用了另外兩個 macros，_MIN 與 _MAX 來補救，但考量到跨平台程式設計，這兩個 macros 有跟沒有一樣。後者就真的很傷腦筋了，很多時候，numeric_limits<> 的使用是無法避免的[1]，但當直接或間接 #include 進 <windows.h> 的時候，VC6 就會出現 C4003 warning 然後後面的程式就爛掉了。
通常來說，碰到這種相容性問題，先找看看 Boost 怎麼作就對了[2]。於是我在 boost/config/suffix.hpp 裡，發現了 BOOST_PREVENT_MACRO_SUBSTITUTION 這一個 macro，被安插在可能被 VC6 搞爛的 min/max 後面，括弧前面。其用法如下：
std::max BOOST_PREVENT_MACRO_SUBSTITUTION(value1, value2);
// or
std::numeric_limits<Foo>::max BOOST_PREVENT_MACRO_SUBSTITUTION();
實際上，BOOST_PREVENT_MACRO_SUBSTITUTION 是空的，會被代換成沒有任何東西，其目的應該是為了騙過 preprocessor，使其認為 min/max 不是 VC6 [...]
#define N 3
嗚啊啊啊啊～～我快瘋了！怎麼會有人聰明到，在 .h 檔裡面，寫出這樣子的程式呢：
#define N 3 // number of states of a xxx model
為什麼我會突然有股衝動，很想要像網路上流傳的某段影片，拿起鍵盤狠狠地把電腦砸個西巴爛呢？讚，據說我還要一年半才畢業。讚，據說畢業之後，也還是得考慮五斗米的問題。
Creating menu bar in PPC2003 dialog based APP, in VS.2005
C++/MFC 在新版的 Visual Studio 上真是多災多難啊，不曉得是不是因為微軟要推崇 .Net 的關係。最近我就碰到了這個問題，還好最後透過神奇的股溝大神，找到了個神秘的討論串，再經過奇妙的測試過程，終於搞定了這個莫名其妙的問題。
我需要的是，在 PocketPC 2003 Dialog based 的 MFC 程式上，裝上 menu bar。
可是 Visual Studio 2005 不讓我把 Menu 綁在 Dialog 上，找 Pocket PC Developer Network 得到這一篇文章：《QA: How can I insert menu in a dialog?》，說按照這一篇《QA: How can I use a command bar in a dialog?》的說法，MFC 在 CDialog 裡留了一個小尾巴，放了一個叫 m_pWndEmptyCB 的 protected member variable，將之強制 [...]
Doxygen syntax coloring in Vim
Vim 的 syntax coloring 功能強大，讓人愛不釋手；而 doxygen 的出現，讓 C、C++ 甚至 Perl，也都能有像 Javadoc 那樣的 in-code documentation solution。如果能夠兩者結合，如許多 Java IDE 在 editor 裡對 Javadoc 的支援那樣[1]，連 comment 裡的文件內容，都能夠把 syntax coloring 弄得漂漂亮亮的，那就更棒了。
剛剛在逛 doxygen 網站，被我發現這個 script：《DoxyGen Syntax : DoxyGen Highlighting on top of c/c++/java》。簡單說，就是能夠在原本 Vim 對 C/C++/Java/... 的 syntax coloring 的基礎上，再增加對註解裡 doxygen 文件內容的 syntax coloring。於是趕緊抓下來試試。
網頁上的安裝方法比較複雜，我試了幾次沒有成功。所以就研究了一下 Vim 的 online document，發現 *mysyntaxfile-add* 這一節這麼說道：
If [...]
Right libiconv version for Windows
最近在整合 libiconv，希望能夠解決一些跨平台[1]文字轉碼的問題。程式寫得很高興，結果移到 Windows 上一執行，卻不能執行，檢查的結果，是不支援 WCHAR_T，嘗試改轉成 UCS-2LE 或是 UTF-16LE，雖然可以轉，但有些字還是會爛掉。經過追查的結果發現，一切都是版本的問題。
對於曾經體驗過 GNU、Linux 以及其他 Open Source 軟體的好處的人來說，如果能夠也在 Windows 平台上，使用這些工具，那可真是一大樂事，多少能夠讓 Windows 變得稍微好用一些。因此，一直以來，這些 open source 軟體，不斷有官方或非官方的人或組織，在進行著 windows porting 的工作。大喀的有 Cygwin/MingGW，小喀的也有 UnxUtils 這類計畫存在[2]。而在 libiconv 的官方網站裡，也可以下載的到一個叫做 libiconv-1.9.1.bin.woe32.zip 的特別版本，將這個版本解開後，通常是放到 C:\usr 下，設定好 PATH 環境變數，即可使用。這正是原本我在 Windows 上使用的 libiconv 版本。
但今天卻發現，這個 1.9.1-woe32 的版本，compile/link 程式都沒有問題，但就是沒有 WCHAR_T，也會讓 UCS-2LE 或 UTF-16LE 的某些字爛掉。測了一下從 google 找到的幾個 libiconv for windows implementation，發現 GnuWin32 所提供的 libiconv，並沒有這個問題。換用了這個版本，跑一遍所有的 [...]
Borland 要賣掉他的 Windows/Java 開發工具了
從反微軟資訊新聞的這篇《要付費的軟體發展工具即將成為歷史？》看到的消息，原始來源是 The Register 的這篇《Borland rides Segue on trip out of IDE biz》：Borland 要賣掉他的 Windows/Java 開發工具了，改行搞 software performance 了。
真是令人惋惜但不意外的消息。因業務挫敗導致政策的搖擺，繼而導致產品品質的不穩定，再加上一向秉持的封閉軟體特性，當沒有夠成熟的開放軟體與之競爭的時候，還可以叱吒一時，但若是人們有得選擇時，天平就會擺到不會被綑綁的開放軟體的那邊。
Can't just say "No" to bad old programmers
最近一直很忙，工作環境裡的一些困境一直在困擾著我，並不是沒有技術可以滿足種種需要，而是這些技術都無法被使用，猶如「被綁縛了雙手的俠客」一般，頓時失去了練在雙手上的功夫，連三歲小孩也打不過。看來，要能武功大成，無論在何種境界皆能自在充裕，還有好大好大的一段距離要努力啊。
拜讀 Jserv 的這篇《思索 C++》，裡面引的這句「just say "No" to bad old platforms」挺有意思的，可惜在軟體工程上，決定一切的通常不是技術因素，而是「錢」。「錢」最為優先，次之為「人」，最後才是「技術」。
小弟我有幸身在一個比較沒有市場壓力的研究單位，因此不需要直接面對「錢」的問題。但相對地，「人」的問題，便首當其衝。這兩年來的整理思考，讓我明瞭了，在實務工作上，除了常要 cross platforms 外，還常常需要 cross programmers，不僅 platform 要跨，連 programmer 也要跨。期待所有會使用到你的程式的 programmers 都能具有某些基本能力，就跟期待碰到的 platforms 可以支援基本的 C99/C++98 一樣，緣木求魚。
更慘的是，我們無法 just say "No" to bad old programmers，因為，不僅 team members 會碰觸到你的程式，你的 customer 也有可能會碰到你的程式。在客戶至上的大前提下，是沒有可能因為客戶不懂 template，就 just say "No" to dummy customers 的。最終，還是得弄出一套 pure C 版本朝聖才行。喔，客戶的問題可能還好解，大不了另外寫個 library [...]
