COdE fr3@K

Status Update, Mid 2009

2009-06-28T02:27:45Z

接下來幾個月, 打算把較多的閒暇時間用在一個 “低調計畫” 上. 因此, 預期將減少產出有意義的原創文字.

這個 project 當然是用 C++ 寫些東西. Scope 不大, 因此只要不擺爛, 一個人也一定寫得完. 簡單的說是要 re-implement 一個已存在並被不少人使用的 FOSS project. 將大量使用 Boost. 特別是已經一年多沒碰的 Asio, 以及很可惜一直沒玩到的 Multi-Index. 可以說是拿 Asio 來挑戰 libevent.

如果能較前人的貢獻有更好的 performance 當然最好. 即便不如期望, 也希望可以有機會找出不能 out-perform 的原因或線索. 或許能回饋給 Boost/Asio, 提供改善的方向. 無論如何, this is gonna be fun.

另, 如果你覺得閱讀小弟的文字不算是一件太浪費生命的事, 建議參觀/訂閱我的 Shared Items (via Google Reader).

STL Performance Boost in VS2010

2009-06-29T07:54:06Z

幾個月前曾在一篇文字裡寫道: 正確的運用 Rvalue References, 有可能帶來可觀的 performance gain. 前幾天看到 Visual C++ Team Blog 新貼出對 STL (VS2010 vs. VS2008) 的 performance benchmark. 在一個程度上, 該篇文字可以說驗證了這個不只我一個人獨有的看法與對 C++0x 的期待.

Rvalue-References 帶來的 performance boost 或許比不上 Multi-Core STL 來得那麼 “方便”, 但絕對是你不會想要錯過的 low hanging fruit.

C++0x 的巨浪就要來了, 你準備好了嗎?

Wordpress Installation Upgraded

2009-06-25T12:11:49Z

成功把 wordpress 從 2.3.x 升級到 2.8. 照著官網上的說明一步一步做, 過程不算輕鬆但也不困難.

或許是因為本來就很陽春, foundation theme 似乎完全沒有問題, 這下沒那麼急迫需要換 theme 了.

考慮換成 Pixel theme, 慢慢改裝中.

Blog Pwnd, Again

2009-06-24T10:43:22Z

又被 hack 了, (上一次的紀錄) 這次的狀況跟這邊說的一樣. 準備升級至 Wordpress 2.8.

一直用的 foundation theme 早已是個孤兒沒有人維護, 換哪個 theme 才好呢?

The “Zw” Prefix

2009-06-05T03:02:07Z

I’ve always wondered: What does the “Zw” prefix (of some NT kernel functions) mean?

As it turns out – nothing.

It’s Better Without Asus

2009-05-30T11:07:02Z

Okay. Asus, this move is not cool.

Perhaps it’s better without you, altogether. Bye.

Cited from: The Register.

Observer Pattern, Done Differently

2009-05-25T18:47:47Z

In a recent post of Scott Wheeler's - C and C++ are not the same language. He talked about differences between C and C++, and applications of different programming languages (C, C++, Java, Ruby) in his company.

In the post, Wheeler implemented observer pattern in C, C++ and Java, demonstrating some of his points - including how C and C++ are different from each other, and how C++ and Java are actually more alike.

Though I do agree with Wheeler's conclusion for the most part, I failed to share his view in C, C++ and Java comparison. IMHO, his observer implementation in C++ is rather old school, or should I say it's so Java.

In C++, oftentimes, there are more than one way to get you from point A to point B, while OO (inheritance) is the one feature that expresses coupling the most. In modern C++, when there is a way to do something without involving inheritance (read "tight coupling"), it is usually appreciated. One such way to implement the subject in observer pattern is:

Listing 1

PLAIN TEXT

C++:

class subject
{
public:
void register_observer(
const boost::function<void ()>& observer)
{
observers_.connect(observer);
}
void notify_observers() const
{
observers_();
}
private:
boost::signal<void ()> observers_;
};

With help from Boost, nothing from subject, (or the Listener interface used in Wheeler's implementation) except the signature of expected observers, are exposed to Observers (actually, the signature is exposed mostly to programmers). They are decoupled from each other. Next, let's see what types of observers can be utilized with this subject implementation:

Listing 2

PLAIN TEXT

C++:

class foo_observer
{
public:
void notify()
{
cout <<__PRETTY_FUNCTION__ <<endl;
}
};
class bar_observer
{
public:
bar_observer(unsigned int id)
: id_(id)
{}
void operator()()
{
cout <<__PRETTY_FUNCTION__ <<'[' <<id_ <<']' <<endl;
}
private:
unsigned int id_;
};
void free_observer()
{
cout <<__PRETTY_FUNCTION__ <<endl;
}

And how are they put together:

Listing 3

PLAIN TEXT

C++:

int main()
{
subject sub;
foo_observer foo;
bar_observer bar1(1);
sub.register_observer(
boost::bind(&foo_observer::notify, &foo));
sub.register_observer(bar1);
sub.register_observer(bar_observer(2));
sub.register_observer(&free_observer);
sub.notify_observers();
return 0;
}

This subject implementation can be used with general objects (e.g. foo_observer), functional objects (e.g. bar_observer), and of course free functions (e.g. free_observer) and more.

Don't be mistaken, though his C++ observer implementation is not among the best I've seen, Wheeler's post is nevertheless a good read. Enjoy.

Full source code: observer.cpp

My First JavaScript – Konami Code

2009-06-08T13:11:18Z

上週在我的 feed reader 上看到了個好玩的東西 - Konami Code.

原文作者引用了 jQuery 主站上的一段 JavaScript, 也明白的說了這個 script 的一個缺陷 - 隨著愈多的 keypress, 它會愈跑愈慢:

It’s a bit sloppy, though: the kkeys array will increase in size with every keypress, which means the page will get slower and slower as you press keys.

把 coding style 調整成自己比較習慣的風格, 加上幾行處理過多 user key log 的 code 以修正原文作者所說的問題, 補上了注解. Here it is, 我的第一個 JavaScript 程式:

PLAIN TEXT

JavaScript:

if(window.addEventListener)
{
var target = "http://fsfoundry.org/codefreak/2009/05/24/my-first-javascript-konami-code/";
var konami_code = "38,38,40,40,37,39,37,39,66,65";
var user_key_log = [];
var max_keys_to_log = 10;
window.addEventListener(
"keydown",
function(ev)
{
user_key_log.push(ev.keyCode); // push_back
var user_keys = user_key_log.toString();
// Searches for konami_code in user_keys.
if(user_keys.indexOf(konami_code)>= 0)
window.location = target;
// Cleans up user_key_log, if its length out
// numbered max_keys_to_log.
while(user_key_log.length> max_keys_to_log)
user_key_log.shift(); // pop_front
},
true);
}

只要你沒把 browser 的 JavaScript 關掉, 在 COdE fr3@K 的任何一頁輸入上上下下左右左右BA, 就會把你帶回到這篇文字.

Tested to work with:

Firefox 3.0.10
Opera 9.64
Epiphany Web Browser 2.24.1

Note: I don't know why, but as the original script from jQuery, my version doesn't work with IE 6 on my XP box at office.

Something interesting that I can't help wondering, 連我這個從沒認真看過 JavaScript 更別說寫過的人都能在知道問題後稍微 google 一下把這問題修掉, 難道 jQuery 網站的作者是覺得這段 code 純屬搞笑而隨便寫寫嗎?

I Like to Move It

2009-05-24T15:01:01Z

喜愛 C++ 並關心 C++0x 標準的朋友一定會知道, C++0x 引進了許多新的元素. 不但對 Standard Library 有為數眾多的 addition 與 enhancement, 連 core language 都新增了不少東西. 而其中最重要的, 在我看來, 就是 Rvalue References. 即便不理會 C++0x 其他的新玩意 Rvalue References 依然是一個職業 C++ programmer 該要掌握的新 feature. 原因很簡單, 正確的運用 Rvalue References, 有可能帶來可觀的 performance gain.

The Stage

兩週前, 在一篇文字中提到了一個因為貪玩寫下的 object 字串化/格式化 utility. 並預告了將在另一篇文字討論, 在 C++0x 的標準下如何對這個 utility 進行優化. Well, here it is. 先回頭看看原來的 code:

Listing 1

PLAIN TEXT

C++:

template <class T>
string str(const T& x)
{
return boost::lexical_cast<string>(x);
}
template <class T>
string operator%(string s, const T& x)
{
return s += str(x);
}

這個 utility 包含了兩個 function template. 使用方法如下:

Listing 2

PLAIN TEXT

C++:

string output = str(123) % ' ' % "abc";

簡單的說, 使用時需先以 function template str 觸發這字串化 utility, 接下來以另一個 function template - operator% - 串接繼續要被字串化的的 object.

The Problem

你知道簡單如 Listing 2 的 use case 會觸發幾次 string 的建構 (與解構) 嗎? 假設每次 lexical_cast 的 invocation 只會觸發一次 string instantiation. 在 compiler 進行了 RVO 之後, 仍有五次 string instantiation.


其中三次是建構從 str/lexical_cast 傳回的 string object,¹ 另外兩次是 operator% 返回時的 copy construction. 前者可說是無中生有,² 是躲不掉的開銷. 而後者兩次的 construction 雖然一樣是閃不掉, 但在 C++0x 的 Rvalue References 加持下, 其 copy 的 overhead 是可以避開的.

The Move
C++0x 的 Rvalue References 可說是為了達成 move semantics 而誕生的產物. 這裡的 move, 是把一個 object 管理的 resource 轉移到另外一個 object 身上的動作. 而 move construction, 則是把一個 object 的 resource 讓出來, 以創建另一個 object:

Listing 3
PLAIN TEXT
C++:




// a function that returns a temporary string.


string unnamed_source();


 


void move_construction_demo()


{


  // move-construct a string using unnamed source.


  string target(unnamed_source());


 


  string named_source(...);


 


  // move-construct another string using named source;


  string another_target(move(named_source));


 


  // "named_source" is now destructible, but not usable.


  // Any reference to it may result undefined behavior.


} 






請參考在之前的文字介紹過的一個字串 class 的 move constructor 以及 move function template 的 definition.
The Solution
有了 Rvalue References, 我們就可以把 Listing 1 的 operator% template 修改成:

Listing 4
PLAIN TEXT
C++:




template <class T>


string operator%(string s, const T& x)


{


  return move(s += str(x));


} 






在這個例子中, 只要在回傳前對 s += str(x) 的結果 - an lvalue (reference to a string) - 呼叫 move, 就能把原本的 copy construction 變成 move construction. 當然也避開了 copy 的開銷.
那為什麼不需要對另外一個 function template - str - 一併做 move? 由於來源是 rvalue (lexical_cast 的傳回值), 而 C++0x 的 string class 也有 move constructor. 在這組合的配合下, move 會自動發生. 即便 string class 沒有 move ctor, 從 lexical_cast 傳回的 string instance 也會被一路 RVO 到 str 的 caller,³ 其效果就跟被 move 了是十分接近的.
The Conclusion
C++0x 就要來了. 你能做的最好準備, 就是讓自己熟悉 Rvalue References. 它不是個 fancy feature, 而是能夠實實在在主宰程式的效能的 killer feature.
當 function 是以 return by value 方式傳回一個 named instance, 請記得: "We like to~~ MOVE IT!!!"

Full source code: move-it.cpp.
Compile using g++ 4.3.2: $ g++ -std=c++0x move-it.cpp

經過 RVO 之後, 已無法區分 str 與 lexical_cast 傳回的 instance. 兩者融為一體. [↩]
從沒有 string object 到有 string object. [↩]
至於這樣的 RVO 會不會真的發生, 就要看 compiler 優化的功力了. [↩]



New Job Openings at Work
2009-07-02T02:43:54Z
今天下午老闆的老闆跟我說, 他的手上也就是我現在服務的部門新增了二十個職缺, 並鼓勵我對外宣傳這個招兵買馬的訊息.
工作會是跟我同一個部門, 但應該不會是同一個 可能也有機會來我的 team. 細節還不清楚, 我就這個部門 common 的部份說明.
上班地點在台北市. 部門的主要責任是建置 cloud computing 的 infrastructure, 以及設計研發運行於這個 infrastructure 之上的 framework 與 application.
一定會用到的 hard skill 有:

Unix based. CentOS 5.3 is the choice of development and target platform of my team, choices among teams may vary.
System/network programming.
Proficiency at one or more of the following system programming languages; C, C++ and Java. There are teams, like mine, which does C++ mostly, and there are other teams those do Java or pure C.
Familarity with Free and Open Source Software. It would be foolish and arrogant if we were not to leverage existing and proven FOSS technologies when available. We use FOSS in conformance to their licenses.

還有一定會加分, 多數人遲早要用到, 但不是每個人都得現在就會的技術:

Knowledge in networking protocols. General TCP/IP and HTTP in particular. The more the better.
Distributed computing. e.g. distributed filesystem/database, MapReduce.
Relational database. e.g. PostgreSQL, MySQL.
Scripting. Most teams, if not all, use scripts. Just in case if you are curious, my team uses Perl for scripting.
Data mining.
Knowledge in Information Security.

不蓋你, 在個人這十年 software engineering 工作職涯裏, 就屬現在服務的公司最把軟體研發當一回事, 員工的福利也最好.
有興趣, 熱愛挑戰的朋友可以把履歷 email 給我.¹ 也歡迎把這個訊息轉告給其他的朋友. 轉貼時最好以 link 的方式進行, 以方便取得更新資訊.

連絡方式:

echo gsfbl.gtgpvoesz@psh | tr b-za.@ a-z@.


If you can't figure out my email address from the above code, you really shouldn't be emailing me. Sorry.

雖然小弟我沒有錄用與否的決定權, 但可以確保你的履歷被 forward 到正確的人手上, 免去被看不懂的人 filter 掉的風險. [↩]





Author of NoScript Apologized
2009-05-24T13:44:01Z
Giorgio (author of NoScript) apologized and explained things from a somewhat different (i.e. his) perspective.
As Giorgio said himself, it was wrong and there is no excuse. Though, from a user's point of view, I do not agree with his doings in this instance. However, from a geek's (i.e. my) point of view, they were not unthinkable.
My take, Giorgio was hacking, not for the greater good obviously, but there was no intention to takeover the world (or helping bad guys doing so) neither. That is if it is his true thinking that he told us.
For now, I am keeping NoScript.






NoScript Gone Bad!? WTF!
2009-05-24T13:43:47Z
Users of NoScirpt, read this (in Chinese) and this (in English)!
I am researching for alternatives to NoScript, if anyone has any idea, please drop me a line.
[Update]

Author of NoScript apologized.






Output Stream Type Preservation
2009-05-19T04:37:29Z
上週看到了一篇引起我興趣的 blog - C++ Format String using boost::format. 冒著再次被人指為 屁的半死 的風險, 身為男子漢的我, 還是決定把心中的 替代解法 寫給了 Hubert 參考. Hubert 建議用 Boost.Format 的解法很好, 可我就是就是忍不住貪玩啊.
緣由交代完了. 有興趣看給 Hubert 參考的解法的朋友請自便, 因為接下來要談的不是它¹, 而是另一個沒那麼漂亮, 但卻挺有趣的解法.




相信很多人都有這樣的需求 - 把 object 轉成 human readable string, 或許經過簡單的 formatting. 我一開始想到的就是:

Listing 1
PLAIN TEXT
C++:




// Assuming `foo` is an integer.


ostringstream oss;


oss <<"The value of foo is: " <<foo;


string output = oss.str(); 






雖然這完全是能達到我的目的, 但也正如 Hubert 說的:
總覺得透過 operator += 以及 stringstream 等東西，並沒有辦法像 sprintf 那樣直覺而優雅的將變數置換至字串當中。
那把對 oss 做 insertion 的 code 跟對其呼叫 str() member function 的 code 寫在一起會不會稍微優雅些? 把 Listing 1 的三個 statement 縮減成兩個:

Listing 2
PLAIN TEXT
C++:




ostringstream oss;


string output =


  (oss <<"The value of foo is: " <<foo).str(); 






的確就稍微好那麼一些些 ><. 如果這段 code snip 可以 compile 的話.
對 ostringstream 的 instance (actually lvalue) 做 insertion 呼叫到的實際上是它的 base class - ostream 的 inserter. 這些 inserter 的 return value 當然也是 ostream&. 換句話說, 對 ostream 的 derived class 的 instance 做 insertion, 在沒有特殊的 overload 的狀況下, return value 都不會是 derived class 的 reference. 也因此無法對這些 return value 呼叫 derived class 的特異功能; 例如 ostringstream::str() - 把 insert 到 ostringstream 的 buffer 的內容轉成 string 傳回來.
在我看來, Listing 2 雖不合法, 但會是好用的語法, 可以把 code 寫的更乾淨利落. 於是我考慮了下面的 inserter template:

Listing 3
PLAIN TEXT
C++:




template <class OutputStream, class T>


OutputStream& operator<<(OutputStream& os, const T& x)


{


  ostream& base = os;


  base <<x;


  return os;


} 






由於要能夠給各種繼承自 ostream 的 output stream 使用, 因此第一個參數 - OutputStream - 的 type 得是個 template parameter, 才能讓 compiler 認為這個 template 是比 base class (ostream) 的 inserter 更好的選擇. 但也因此引發兩個使它無法被使用的 side effect:

這個 template 會影響所有 user-defined type 的 operator<<, 原本沒問題的 code 在有了這個 template 後可能無法 compile 或正常運作.
當 template parameter OutputStream 已是 ostream 時, 這個 template inserter (inserter template 實例化所產生的實體) 會沒完沒了的 recursive 自己 call 自己, 會在 run time 發作直到把 stack 吃光為止.

也考慮過換個 operator 來實現這樣的功能, 例如 operator%, 但那依然無法解決上述的第一個 side effect, 只是換個 operator 出問題. 於是還是請出了 Boost:

Listing 4
PLAIN TEXT
C++:




template <class OutputStream, class T>


typename boost::disable_if<


  boost::mpl::or_<


    boost::mpl::not_<


      boost::is_base_of<ostream, OutputStream>>,


    boost::is_same<OutputStream, ostream>>,


  OutputStream>::type& operator<<(


    OutputStream& os, const T& x)


{


  ostream& base = os;


  base <<x;


  return os;


} 






Note: 由於不明原因, 我用的 code highlighter plugin 會把某些空格省略掉. 這通常不會造成明顯的問題, 結果依然是合法的 code. 但在 Listing 4 的 line 5 and 6 的結尾, 這個 plugin 把應該是 > > (中間有 space) 的 code 顯示成在現行標準下不合法的連續兩個 >. 請特別注意. 

宣告這個 inserter template 的 Listing 4 可以這樣解讀; 不讓 compiler 考慮 (boost::disable_if) 採用這個 template (同時也不會有具體實現這個 template 的問題), 如果下列某個條件成立 (boost::or_):

ostream 不是 (boost::not_) OutputStream 的 base class (boost::is_base_of).²
OutputStream 就是 (boost::is_same) ostream.

這段 code 既繞舌又不好寫. 連屁的半死的我也寫了超過十分鐘才寫對. 不過結果看起來不錯, 保留了output stream 做 insertion 之前的型別, 也在沒有明顯的 side effect 的情況之下讓類似 Listing 2 的操作合法了.
Full source code: ostream_type_preserve.cpp

下一篇文字 才要進一步談寫給 Hubert 參考的解法, 以及在 C++0x 的標準下優化的方法. [↩]
如果 boost::is_base_of 的兩個 template parameter 相同時 - e.g. boost::is_base_of<X, X> - result 為真. [↩]





Contemplation of Prejudice
2009-05-24T12:51:26Z
Not long ago, I blogged about how it was difficult to adopt Free libraries in my previous projects at work.
Just today, when I was exploring the compay repository, I see boost sits comfortably under a folder named "3rd_party" in one of my previous projects, along with a couple of tiny Free libraries I wrote.
Apparently, I was wrong and didn't try hard enough. Going to find the man who made it happen and pay him my respect tomorrow.






DDJ Stopped Printing
2009-04-06T13:55:22Z
今天感冒了, 掛病號在家裡睡覺. 一個朋友告訴我,  DDJ 停止了實體雜誌的發行.
雖然我不是每期必看 DDJ 的忠實讀者, 但這個消息依然讓我不開心了一天. 只是這事件對我來說怎麼也比不上三年前 CUJ 被併到 DDJ 的感傷.
安息吧, CUJ.






[Note] Installing Review-Board on Ubuntu Linux 8.10
2009-03-30T16:27:43Z
This is a note to myself just in case if I have to do it again - installing a Review Board server.
The installation process took me more than a few hours and spanned over three days. Here are the few things that caused me a grief. They are things I managed to remember and are by no mean complete.



Read and follow the instructions here then here very carefully. Don't miss a thing!
Try satisfing Review Board's dependencies in advance might help. I installed all dependencies (those I could find) listed in its document before I begin installing it, i.e. easy_install ReviewBoard. After all, my installation seems to be successful, at least for for the time being. Oh, BTW, its dependencies is scattered pretty much everywhere in the first link in item 1 above.
Much of the installation process took place in terminal, i.e. text mode. Pay attention to the output message while building, installing and etc. I was lucky to notice an error when installing one of its dependencies, it was not obvious enough, for me anyway. This saved me from spending (only-god-knows-how-much) more time troubleshooting.
On this server Review Board was installed, though I failed to recall which, there was one thing or two missing in the dependencies listing in its documentation. If things are not working, crawl through its log and figure out what's missing or miss-configured. It wasn't difficult to tell what was wrong in my case.
Make sure you change the permissions for its "db" folder, i.e. chown -R www-data /var/www/reviews.example.com/db, while you are changing the permissions for its "uploaded" folder. I had to do this for using sqlite, not sure if it is needed for using other DB backends.
I had to remove the site configuration Review Board installed, and modify my /etc/apache2/sites-enabled/000-default for things to work, in the contrary to what was suggested in its Note section near the end of this page. Note that, my server runs web applications in sub-folders (instead of VirtualHosting that is).
If your server runs web applications in sub-folders like mine, there is a chance Review Board may break your applications. In my case, my MediaWiki installation was broken. For someone who is not proficient with Apache administration, e.g. me, you will need a friend who is capable of, and willing to help you configuring Apache. Thanks Tye.







Re: Domain-Specific Language (DSL)
2009-04-06T14:16:42Z
Keiko 寫了篇 討論 DSL 的文字. 這篇文字不短, 有層次. 有他說的 "學院派式" 的格調. 讓我有一種在看一份探討輪胎直徑與胎壓以及胎壁厚度之間關係的 paper 的 feel. 相形之下, 這裡寫的東西看起來更像是黑手示範如何補胎換胎的 howto.
好了, 細節不多談, 建議自己去參觀一下. 重點是, 本要在 comment 裏寫 code, 但這該死的 blogger 超難用, 讓我想起當年 從 blogger 離家出走 的原因.¹ 又扯遠了, 回到我想回應給 Keiko 的東西.




文字中一段談到 metaprogramming 可以把部份的 domain-specific 錯誤偵測從 run time 往前拉到 compile time. 文中以這樣的 interface 為例:

Listing 1
PLAIN TEXT
C++:




template <int RowT, int ColT>


class MyMatrix {


public:


  // !fr3@K! Detail omitted.


  MyMatrix();


};


 


// !fr3@K! This explicit declaration is added to help 


//         expressing my point.


template <int RowT, int ColT>


MyMatrix<RowT, ColT> operator +(


  const MyMatrix<RowT, ColT>& lhs,


  const MyMatrix<RowT, ColT>& rhs ); 






在這樣的 use case 時:

Listing 2
PLAIN TEXT
C++:




MyMatrix<10, 10> m1;


MyMatrix<2, 2>   m2;


 


cout <<m1 + m2 <<endl; 






會產生下面的 compile time error diagnosis (in MSVC 2005):

error C2679: binary '+' : no operator found which takes a right-hand operand of type 'MyMatrix' (or there is no acceptable conversion)

雖然 compiler 已經把錯誤抓到了, 可是錯誤訊息卻不是很友善. 你希望能有 "incompatible dimensions" (domain-specific error) 的提示. Okay, 讓我這個黑手示範一下在這個 use case 下, 怎麼樣叫 compiler 吐出 "incompatible dimensions". operator+ 的宣告要改成類似這樣:

Listing 3
PLAIN TEXT
C++:




template <


  size_t RowLhs, size_t ColLhs,


  size_t RowRhs, size_t ColRhs>


MyMatrix<RowLhs, ColLhs> operator +(


  const MyMatrix<RowLhs, ColLhs>& lhs,


  const MyMatrix<RowRhs, ColRhs>& rhs); 






通常, 好的 interface 會儘量設計成不允許錯誤的使用被 compile, 並且讓錯誤發生的時機愈早愈好. Keiko 舉的 use case 所引發的錯誤就是一個例子, 若用 Keiko 的 interface, 這個錯誤會發生在 operator+ 的 caller site, 也就是 Listing 2 的 line 4. 但我為了讓 error message 能更為明確, 選擇反向操作 - 讓 operator+ 的 caller site 能被 compile, 將錯誤 defer 到 operator+ 的裏面發生. 實作為:

Listing 4
PLAIN TEXT
C++:




template <


  size_t RowLhs, size_t ColLhs,


  size_t RowRhs, size_t ColRhs>


MyMatrix<RowLhs, ColLhs> operator +(


  const MyMatrix<RowLhs, ColLhs>& lhs,


  const MyMatrix<RowRhs, ColRhs>& rhs)


{


  static_assert(


    RowLhs == RowRhs && ColLhs == ColRhs,


    "incompatible dimensions");


 


  MyMatrix<RowLhs, ColLhs> tmp;


  return tmp += rhs;


} 






我手邊沒有 C++0x 的 compiler, 無法確切告訴你 static_assert 實務上會吐出怎樣的錯誤訊息. 但沒意外的話, 應該會是 Keiko 想要的 message.²
沒有 C++0x 的 compiler? 沒關係, 還有 Boost.StaticAssert:

Listing 5
PLAIN TEXT
C++:




template <


  size_t RowLhs, size_t ColLhs,


  size_t RowRhs, size_t ColRhs>


MyMatrix<RowLhs, ColLhs> operator +(


  const MyMatrix<RowLhs, ColLhs>& lhs,


  const MyMatrix<RowRhs, ColRhs>& rhs)


{


  BOOST_STATIC_ASSERT(


    (RowLhs == RowRhs && ColLhs == ColRhs) &&


    "incompatible dimensions");


 


  MyMatrix<RowLhs, ColLhs> tmp;


  return tmp += rhs;


} 






雖然吐出的 error message 沒有包含 "incompatible dimensions", 但會 output 出包含 "boost::STATIC_ASSERTION_FAILURE" 的訊息, 並指出發生 static assertion failure 的是 line 4 of Listing 2 所 instantiate 的 line 8 of Listing 5. 只要 programmer 跑過去看就可以看到在 BOOST_STATIC_ASSERT 這個 statement 中的 "incompatible dimensions" 字串. 有點麻煩, 有點陽春, but it still works, more or less.
如果你跟我一樣覺得 Boost.StaticAssert 這樣的行為有點鳥, 可以試試另外一種 static assertion 的 implementation, 類似下面這樣:

Listing 6
PLAIN TEXT
C++:




template <bool> struct my_static_assertion;


template <>     struct my_static_assertion<true> {};


 


#define MY_STATIC_ASSERT(exp, message) \


{ \


  my_static_assertion<((exp) != 0)> ERROR_##message; \


 (void)ERROR_##message; \


} 






並把 Listing 5 的第八行開始的 BOOST_STATIC_ASSERT statement 換成:

Listing 7
PLAIN TEXT
C++:




MY_STATIC_ASSERT(


  RowLhs == RowRhs && ColLhs == ColRhs,


  incompatible_dimensions); 






這時候的 error output 會像下面這樣 (using gcc):

error: ‘ERROR_incompatible_dimensions’ has incomplete type

這個 implementation 有一個很明顯的 limitation, 看 實作 就會知道它要的 message 只能是一個字 (誤). No space, no symbols except underscore (底線/下滑線). 所以在 Listing 7 的例子裏, 用的是 incompatible_dimensions, 而不是更容易讀的 incompatible dimensions.
Have fun!

搬家的另一個主因是當年 blogger 沒有 tag/label. [↩]
這裡 有個實例. [↩]





Code Review – ActiveMQ-CPP
2009-03-10T12:15:22Z
上一篇寫到 不識貨的我不欣賞 ActiveMQ-CPP "仿 Java" 的 design 哲學. 或許是我太機車了, 畢竟這是主觀的. 一個特定 design 哲學及其產物一定是有好也有壞, 評價的高低端看它的強項是否能被人欣賞, 缺點是否能被接受 (忍受). 今天讓我們來幫 ActiveMQ-CPP 做個 code review, 從 C++ coding 來看看能不能幫 Apache 扳回一城.



先從 ActiveMQ-CPP 的一個 example 看起. 下面是其中一個 class 的 dtor (destructor) 的 code snip (details omitted):

Listing 1
PLAIN TEXT
C++:




class HelloWorldProducer : public Runnable {


public:


    virtual ~HelloWorldProducer(){


        cleanup();


    }


 


private:


    void cleanup(){


 


        // Destroy resources.


        try{


            if( destination != NULL ) delete destination;


        }catch ( CMSException& e ) { e.printStackTrace(); }


        destination = NULL;


 


        try{


            if( producer != NULL ) delete producer;


        }catch ( CMSException& e ) { e.printStackTrace(); }


        producer = NULL;


 


        // Close open resources.


        try{


            if( session != NULL ) session->close();


            if( connection != NULL ) connection->close();


        }catch ( CMSException& e ) { e.printStackTrace(); }


 


        try{


            if( session != NULL ) delete session;


        }catch ( CMSException& e ) { e.printStackTrace(); }


        session = NULL;


 


        try{


            if( connection != NULL ) delete connection;


        }catch ( CMSException& e ) { e.printStackTrace(); }


        connection = NULL;


    }


}; 






Listing 1 的 line 12, 17, 23, 28, 33 都在 delete 之前先測試要被 delete 的 pointer 是否為 NULL. 這其實是 完全沒有必要的. 至少在使用符合 Standard 規範的 Standard Library 實作或是符合 Standard 規範的 user-defined operator delete 時沒有必要.
接著可以注意到這些 delete statement 都位於 try block 裏面. 這比較奇怪, Apache 認可的 C++ contributor 還有人不知道當 object 在 destroy 的時候遇到錯誤, 寫個 log 甚至是打電話給你的阿姨都比在 dtor 裏面拋出 exception 來得好!¹ 在這驚魂未定之際 trace 了幾個被 delete 的 class (from derived to base classes) 的 dtor, 發現它們都是空的, 也就是說根本不會有 exception 發生的可能. 更別提不允許 dtor 拋出 exception 是 Standard 明白規定的.
也許 ActiveMQ-CPP 的人不認同 Standard 或是其他 Guru  的意見, 寧願讓 dtor 可以拋出 exception. 而為了搞不清楚到底哪些會 throw, 就全部 try/catch 起來. 在我沒看完所有的 dtor code 的狀況下, 我願意相信 Apache/ActiveMQ 的人不是出於對 C++ 的熟悉度不夠, 而是選擇這樣做的. 其實這個猜測已經與 HelloWorldProducer 的 dtor 的思維背道而馳了, One allows exceptions to propagate out of dtors, the other catches and absorbs all exceptions in dtor. 撇開這些的有的沒的, HelloWorldProducer 的 dtor 已是萬無一失了嗎? Well, not quite.
HelloWorldProducer::cleanup() 的所有 catch block 裏面都做了同樣一件事 - 把 exception 所經過的 stack trace 輸出到 std::cerr, i.e. e.printStackTrace(). Code snip from decaf/lang/Exception.cpp:

Listing 2
PLAIN TEXT
C++:




void Exception::printStackTrace() const {


    printStackTrace( std::cerr );


}


 


////////////////////////////////////////////////////////////////////////////////


void Exception::printStackTrace( std::ostream& stream ) const {


    stream <<getStackTraceString();


}


 


////////////////////////////////////////////////////////////////////////////////


std::string Exception::getStackTraceString() const {


 


    // Create the output stream.


    std::ostringstream stream;


 


    // Write the message and each stack entry.


    stream <<message <<std::endl;


    for( unsigned int ix=0; ix<stackTrace.size(); ++ix ){


        stream <<"\tFILE: " <<stackTrace[ix].first;


        stream <<", LINE: " <<stackTrace[ix].second;


        stream <<std::endl;


    }


 


    // Return the string from the output stream.


    return stream.str();


} 






Line 2 and 7, 在沒有檢查 exception mask 的前提下, 對 std::cerr 做 insertion 有可能拋出 exception. 雖然 default 是不會, i.e. basic_ios::exceptions() 為 ios_base::goodbit, 但 std::cerr 為一 global variable, 誰能保證它的 exception mask 不會被 client code (甚至是 ActiveMQ-CPP 的其他部份) 改變?
說到 IOStream default 不會 throw, 因此在 Exception::getStackTraceString() 內對一個 local 的 std::ostringstream instance (stream) 做 insertion 不會 throw. 但是 stream.str() (basic_ostringstream::str()) - 由於以 return by value 的方式回傳一個 std::string - 卻有可能 throw.² 結果就是 HelloWorldProducer 的 dtor 不但沒有成功地將所有可能的 exception 攔住, 反而增加了在 catch block 內發生沒被處理的 exception 的可能. 而比在 dtor 內拋出 exception 更糟糕的是 - 這狀況會讓程式立即 terminate.
ActiveMQ 是實作來給 enterprise grade application 使用, 做為做 message transport/routing, 該要 "非常非常 robust" 才對. 上面談到的問題點畢竟都不是源自 production code, 或許不該被拿來太認真檢驗, 只能說它是很糟糕的 sample code. 可是往更深入的地方繼續 hack, 看到的卻是整個 ActiveMQ-CPP 的 exception handling 都不及格.
隨便選個檔案挑個 function, activemq/core/ActiveMQConnection.cpp:

Listing 3
PLAIN TEXT
C++:




ActiveMQConnection::~ActiveMQConnection() {


    try {


        this->close();


    }


    AMQ_CATCH_NOTHROW( ActiveMQException )


    AMQ_CATCHALL_NOTHROW( )


} 






Note: 挑 ActiveMQConnection 的 dtor 來說明是因為它短, 與它是個 dtor 無關.
其中 AMQ_CATCH_NOTHROW 的定義如下 (in activemq/exceptions/ExceptionDefines.h):

Listing 4
PLAIN TEXT
C++:




#define AMQ_CATCH_NOTHROW( type ) \


    catch( type& ex ){ \


        ex.setMark( __FILE__, __LINE__ ); \


    } 






而 ActiveMQConnection::setMark() (source) 為一 proxy function, 轉 call 其 base class - decaf::lang::Exception (source) 的 setMark():

Listing 5
PLAIN TEXT
C++:




void Exception::setMark( const char* file, const int lineNumber ) {


 


    // Add this mark to the end of the stack trace.


    stackTrace.push_back( std::make_pair( (std::string)file, (int)lineNumber ) );


 


    std::ostringstream stream;


    stream <<"\tFILE: " <<stackTrace[stackTrace.size()-1].first;


    stream <<", LINE: " <<stackTrace[stackTrace.size()-1].second;


 


    //decaf::util::logger::SimpleLogger logger("com.yadda2");


    //logger.log( stream.str() );


} 






不讓人意外, 光看 listing 5 的第四行就可以猜到 Exception::stackTrace 的型別應該是 std::vector< std::pair< std::string, int> >. 而單是這一行 code, 就 (至少) 有四個地方會產生 exception. (你知道是哪四個嗎?) 看到這裡, 相信你已經知道這個 function 在 catch block 內被呼叫, 若引發了沒有被處理的 exception 的後果 - terminate. 而這樣的 code, 在 ActiveMQ-CPP 裏面到處都是.
ActiveMQ 本身 (由於是以 Java 寫的) 是否不受這篇談的 exception handling 缺失的影響? 雖然 Java 我是門外漢, 但就我所知 C++ 與 Java 的 exception handling model 是很接近的. 因此, 若 hack 進去可能也會發現類似的問題. 那 ActiveMQ-CPP 能用嗎? 除了前面提到的問題之外, 另外還有注意到模組化, 同步最佳化等的 non-critical 問題, 或許我會另外寫一篇文字加以討論.³ 對 JMS/ActiveMQ 不熟悉的我, 要用看的抓出 ActiveMQ-CPP 非語言問題相關的其他問題可說是力有未逮 (at least at the time of writing). 無論如何, 一個打著 Apache 招牌的 project, 我相信它起碼在理想狀態下是能正確運作的, 至少大多數時候.
由於工作上需要使用 ActiveMQ/ActiveMQ-CPP, 希望能在這一兩個星期之內準備個 patch (maybe a few patches) 送給 ActiveMQ-CPP. Java (ActiveMQ) 的部份就要靠另外的善心人士幫幫忙看看有沒有問題.

From [17.3] of C++ Faq Lite [↩]
Exception::getStackTraceString() 也是 return by value, 因此也一樣可能 throw. [↩]
其實 Listing 5 就有無用的廢碼. [↩]





咖啡因中毒
2009-03-09T02:53:39Z
由於工作需要, 這幾天花了點時間看了 ActiveMQ-CPP (from Apache) 的文件與 source code. 第一印象是 - 這票 Apache 的人會不會太喜歡 Java 了?



與 Apache ActiveMQ (core functions in Java) 一樣, ActiveMQ-CPP (client library in C++) 都是拿 JMS (Java Message Service) 來當範本重新實作. ActiveMQ 的部份我沒看進去就不多談了, 只知道是它是個 JMS message router 的實作. ActiveMQ-CPP 就有趣了, 它是 JMS protocol compatible, i.e. 可以與不同 JMS message router/client 的實作互通, 這很好也很正常. 可是看到它仿造 (modeled after) javax.jms 的 API 就另當別論了.¹
不是說 Java 不好 (即便我顯然偏愛 C++). C++ 與 Java 是不同的語言, 除了 syntax 有幾分相似之外², 兩者的編程思維不盡相同, 把 Java 用的 API 近乎完整的 clone 到 C++, 連 utility 都是仿的.³ 我很想知道這裡的 rationale 到底是什麼? 
在多數合理的情況下以 Java 開發軟體比 C++ 容易不少, 這個說法我猜不會有太多人反對. 那為何還是有這麼多人寫 C++? 至少沒聽說過有找不到 C++ 工作的問題.⁴ 除了寫較低階的程式之外, runtime efficiency 可能也是 C++ 依然有它的位置的原因之一. 當然, 也有某些腦筋轉不過來的 programmer, i.e. me, 就只愛寫 C++. 它的迷人之處在於極少設限, 提供使用者 多種 progamming paradigm, 甚至有 多種功能相似的 programming construct 的怪現象.
It's the 21th century! 現在的我們已經知道 許多時候不用 inheritance 能夠架構出更 reusable, 更 low coupling 的 C++ code, 我不懂為什麼 Apache 大神還在跟著 Java 走老路? 要把 code 架構到近 STL/Boost 等 library 的水準的確很不容易, 只是我對掛著 Apache 招牌的 code 的 expectation 不僅如此.
有句話印象中是這樣說的, "別用 C++ 的語法寫 C 的程式". 目的是要提醒從 C 轉到 C++ 的 programmer 要以 C++ 的方式寫 C++ 程式. 例如避免把 class 的 member data 放到 public section, 要以 IOStream 取代 printf() 家族等等. 我想把這句話修改一下也同樣適用, "別用 C++ 的語法寫 Java 的程式". 送給 Apache.

另一個有名的 Apache project, log4cxx 也是仿造 (modeled after) log4j 而來的. [↩]
The language derives much of its syntax from C and C++..., from Wikipedia. [↩]
One example: decaf::io vs. java.io [↩]
不只是 C++, 也包括 Java, 許多其他程式語言也都是能把晚餐帶回家的技能. [↩]





好狗運
2009-03-02T05:51:36Z
過了個年, 世界看來已經變了. 去年十月我還說:
只要有兩把刷子的人願意跟著公司的產品或服務的方向玩, 多的是有人願意付錢讓他們每天玩耍.
不到五個月後的今天, 公司的現金夠多竟是讓我依舊睡的安穩的原因之一.
去年春天在找工作的時候景況還一片大好, 也承蒙面試的長官抬愛有三間大公司願意僱用小弟. 由於種種原因, 我放棄了 M 跟 Y 選擇了加入現在服務的公司. 只是當時的我怎麼也不會想到 M 跟 Y 居然會在這麼短的時間內先後砍掉為數不小的 head count. 我真是好狗運.