COdE fr3@K

You Don’t Have to Resort to Goto

2010-06-30T02:01:05Z

你一定看過這樣的 code:

PLAIN TEXT

int do_something(size_t n)
{
int result = ERROR;
char* buf;
if(n)
{
buf = malloc(n);
if(buf != 0)
{
if(do_foo(buf, n) == OKAY)
{
if(do_bar(buf, n) == OKAY)
result = OKAY;
}
free(buf);
}
}
return result;
}

可讀性差的巢狀 if block, 只為了堅持由一處 return.

想必也看過這樣的 code:

PLAIN TEXT

int do_something(size_t n)
{
char* buf;
if(n == 0)
return ERROR;
buf = malloc(n);
if(buf == 0)
return ERROR;
if(do_foo(buf, n) != OKAY)
{
free(buf);
return ERROR;
}
if(do_bar(buf, n) != OKAY)
{
free(buf);
return ERROR;
}
return OKAY;
}

由多處 return 雖避掉了巢狀 if block, 但需要在多個地方 cleanup 之前所請求的資源.

當然還有這樣的 code:

PLAIN TEXT

int do_something(size_t n)
{
int result = ERROR;
char* buf = 0;
if(n == 0)
goto CLEANUP;
buf = malloc(n);
if(buf == 0)
goto CLEANUP;
if(do_foo(buf, n) != OKAY)
goto CLEANUP;
if(do_bar(buf, n) != OKAY)
goto CLEANUP;
result = OKAY;
CLEANUP:
// free()ing a NULL ptr is a no-op.
free(buf);
return result;
}

不管老師以前是如何叮嚀不要用 goto, 為了閃掉那噁心的巢狀 if block 以及重複的 code, 只好還是用了 goto.

其實還有另一種選擇, 不用重複寫釋放資源的 code, 也不需要用到 goto:

PLAIN TEXT

static int do_something_helper(char* buf, n)
{
if(do_foo(buf, n) != OKAY)
return ERROR;
if(do_bar(buf, n) != OKAY)
return ERROR;
return OKAY;
}
int do_something(size_t n)
{
int result;
char* buf;
if(n == 0)
return ERROR;
buf = malloc(n);
if(buf == 0)
return ERROR;
result = do_something_helper(buf, n);
free(buf);
return result;
}

一旦把 resource management 跟 logic 的部份拆開, code 就好看多了.

獻給一位因為沒有充足理由的規定, 卻在工作中被迫得寫 pure C 的可憐同事.

後記: 這應該是目前我寫的唯一一篇 pure C 的文字. 擔心它太寂寞, 還是把它打上了 C++ 的 tag.

華碩品質, 以卵擊石

2010-06-01T17:24:45Z

很多人可能已經沒印象了. 但我記得很清楚.

去年 5 月底, The Register 所做的一則報導:

Microsoft and Asus have teamed up to present a new advertising smarm-storm intended to extol the virtues of Windows on netbooks - and smear Linux.

而在今天的這則 ZDNet Taiwan 的報導卻又看到:

英特爾表示，宏碁、華碩、戴爾、諾基亞、惠普(儘管已擁有自己的WebOS)等品牌廠商，都已加入發展MeeGo平板的計畫，並有多家OSV、ISV與服務提供廠商來共同建構此生態鏈。

英特爾表示，MeeGo是一款可跨裝置的行動作業系統，將用在手持裝置、小筆電、平板裝置、車用裝置或電視上，此作業系統是基於Linux的開源碼計畫，並獲Linux基金會贊助，目前正由英特爾、諾基亞與開發者社群合作推動。

並登出一張以卵擊石展示機 (?) 的照片:

果真是有堅持有願景的企業啊!

也不知道是什麼時候, 這家以卵擊石的公司已經把那可笑的網站下線了, 現在是個 parking page. 真是後悔當時沒做個 screenshot 留個紀念~

剛剛在 google 以卵擊石的時候發現了一件有趣的事情:

Google 以卵擊石的第一個結果是 tw.asus.com, 可是 google 看到的內容卻是簡體的. WTF.

你怎麼在看簡體的東西!?

2010-05-30T13:17:14Z

"你怎麼在看簡體的東西!?" 不久前, 一位同事在會議中看到我在 NB 上讀到一半的一篇簡體文章, 驚訝地對我說.¹

"醒醒吧老兄. 對岸華人同胞產出的技術性文章, 不論是原創或翻譯, 不管是數量甚至很可能連質量, 都超過我們了啊." 我心理的 OS.

是的, 我的 feed subscription 的數量: 英文 > 簡中 > 繁中.

台灣, 加油好嗎? 要了解自己, 搞清楚自己的強項面對自己的短處. 不必自大也不需自卑, 別成了井底之蛙.

是不是在開玩笑我就不知道了. [↩]

re: 解读google C++ code style谈对C++的理解

2010-05-30T13:12:18Z

想加入這篇解读google C++ code style谈对C++的理解的討論. 不幸由於不明原因, 一直被系統認為是廣告 (圖中紅字部份):

先留個底, 再看看該/能怎麼辦吧.

ps. cppblog 帳號申請中, 也許有帳號就沒這問題了吧? 不過, 看起來申請帳號要經過人工審核...

@那谁
我不懂 Python, (没写过且只看得懂一点点) 我想你说的那份 Google 开源的 Python "没有使用到异常" 不尽正确. 应为 "没处理异常".

以 "class CleansedLines(object)" 的 "__init__" method 为例, 里面有对 list 的 append. 虽然我不清楚 Python list 的实作, 但我很难想像可以对任何一种 list 的实作, 不需要 memory allocation 便可对其 append N (N 未知) 个 element. 一旦需要 memory allocation 就有可能失败, 也就有触发异常的可能. 只是处理与否, 那是另外一回事.

小弟是你的读者, 虽然不完全同意你所有文章的看法. 回应目的为交流, 非论战.

@OwnWaterloo
"那么，换来的结论就是： goolge中的C++程序员，对异常这种编程思想的理解，还不如google中的python和java程序员。"

对 Google 的 coding style 我也得到同样的推论, 我认为可能可以勉强说得通的两个点:
1. C++ 的 programmer 可能较严谨, 因此更认真看待 exception 的发生以及对应的处理方式. 而部份认真的人得到的结论是 "don't do it".
2. C++ 的 exception 较容易导致 memory leak.

後方, 起浪了

2010-05-06T07:59:52Z

後方的浪.

Pic of starryalley on iThome

2010-03-23T16:35:57Z

哈~ 同事 starryalley 的照片上了 iThome.

Quiz on C++ Object Model

2010-03-13T09:58:27Z

這幾個月忙於工作, 這個部落格都快被我給荒廢掉了. 昨晚終於花了時間完成了一篇積了一兩個月, 說明 virtual function 在執行時期的 override 過程以及 virtual function 與 constructor/destructor 混搭結果的文字.

今天我準備了個題目給花了時間看了它的朋友, 當作對小弟的說明能力來個測驗. 請問, 下面的 code snip 的輸出結果是什麼?

PLAIN TEXT

C++:

#include <typeinfo>
#include <iostream>
using namespace std;
struct Base
{
Base()
{
this->print_type_name();
}
virtual void print_type_name()
{
cout <<typeid(*this).name() <<endl;
}
};
struct Derived : Base
{
};
int main()
{
Derived d;
d.print_type_name();
return 0;
}

也就是說, 對同一個, 沒有被 override 過的 virtual function - Base::print_type_name - 呼叫兩次 (第一次是透過 Base 的 ctor 間接呼叫, 第二次則是當 Derived 的 object instance 直接呼叫) 的輸出是什麼? And why?

有些事情, 可以是做爽的. 而這些文字除了幫助降低自己 (主要是在工作上) 對相同主題重複一再說明的負擔, 它們還蘊藏著我的理想性 - 我衷心期望它們能夠對華文技術圈有所助益. 也希望我的說明能力不要太差, 讓這些文字淪落到寫爽的.

Hope you have fun while figuring out the quiz.

當 Constructor 遇上 Virtual Function

2010-03-03T02:24:45Z

Background

不知道你有沒有過這樣的經驗 - 想要在父類的 constructor 裏面呼叫被子類 override (或是 implement) 的 (pure) virtual function?

PLAIN TEXT

C++:

struct Base
{
Base()
: x(0)
{
on_create();
}
virtual void on_create() {}
int x;
};
struct Derived : Base
{
Derived()
: y(1) {}
void on_create()
{
// do Derived specific things
}
int y;
};
void foo()
{
Derived d;
}

我試過. 跟我一樣這樣玩過的朋友, 很快就會學到它不會如你所期望的那樣運作. 如果你的期望是當建構 Derived 的 object instance 時, Derived::on_create 會被呼叫. 要是 Base::on_create 宣告成 pure virtual 的話, 你更會發現它甚至不能 compile.

這樣的結果或許不是那麼直覺, 但背後的原因卻非常簡單 - virtual function 的 override 是發生在 object instance 被建構的時候.

=== mini tutorial ===

Class Derived 的 object layout 長得像下面這樣 (p 為指向一 Derived 的 object 的指標):

       +---------+      +-----------------------------+
p----->|   vptr  |----->| ptr to typeinfo for Derived |
       +---------+      +-----------------------------+
       |    x    |      |      Derived::on_create     |
       +---------+      +-----------------------------+
       |    y    |
       +---------+

由於擁有 virtual function 的原因, Derived 的 object instance 在記憶體中會有一個指向其 vtable (virtual table) 的 vptr (virtual pointer).

=== end mini tutorial ===

Behind the Scenes

打開你的 Inside the C++ Object Model 複習一下. 當我們在程式中建構一個 Derived 的 object instance 時, 先被建構的是其父類 - 也就是 class Base 的部份 - 而後, 才會建構屬於 class Derived 的部份. 這過程可約略分為幾個階段:

準備 Base
起始 Base 的 member, 也就是 Base::x
呼叫 Base 的 constructor
Base 部份建構完成
準備 Derived
起始 Derived 的 member, 也就是 Derived::y
呼叫 Derived 的 constructor
Derived 完整建構

許多人可能不曉得 object 的建構還有上述階段一與階段五的 "準備" 工作. 這裡說的準備, 說穿了其實就是設定 object 的 vptr! 也就是說一直到程式完成步驟五之前, 這個 object 的 vptr 指向的是屬於 class Base 的 vtable:

       +---------+      +-----------------------------+
p----->|   vptr  |----->|   ptr to typeinfo for Base  |
       +---------+      +-----------------------------+
       |    x    |      |        Base::on_create      |
       +---------+      +-----------------------------+
       |    y    |
       +---------+

完成了步驟五, 這個 object 的 vptr 才會改而指向 class Derived 的 vtable. Derived::on_create 正是在這個時候 override 了 Base::on_create:

       +---------+      +-----------------------------+
p----->|   vptr  |--+   |   ptr to typeinfo for Base  |
       +---------+  |   +-----------------------------+
       |    x    |  |   |        Base::on_create      |
       +---------+  |   +-----------------------------+
       |    y    |  |
       +---------+  |   +-----------------------------+
                    +-->| ptr to typeinfo for Derived |
                        +-----------------------------+
                        |      Derived::on_create     |
                        +-----------------------------+

因此, 在例中 Base 的 constructor (也就是表中的步驟三) 參考到的 on_create 不會是被 Derived override 的版本.

With a Little Twist

前面提到如果 Base::on_create 被宣告成 pure virtual, 任何嘗試建構 Derived 的程式將不能成功編譯.

因為在這情況下, (假裝這樣的程式可以 compile 並運行) 在開始步驟三時 object 的 layout 會是像這樣:

       +---------+      +-----------------------------+
p----->|   vptr  |----->|   ptr to typeinfo for Base  |
       +---------+      +-----------------------------+
       |    x    |      |    <pure virtual marker>    |
       +---------+      +-----------------------------+
       |    y    |
       +---------+

Compiler 會在 class Base 的 vtable 內, 原本紀錄著 Base::on_create 的欄位標上一個特殊的 marker 以表示該 virtual function 為 pure virtual. 既然 pure virtual function 是不能被使用者以有意義的方式參考, 間接呼叫了 pure virtual function 的 Derived 的 constructor (Derived ctor -> Base ctor -> pure virtual) 當然也是無效的.

What About Destructors

在 destructor 內呼叫 (pure) virtual function 也有完全一樣的問題. 只要把文中 object 建構的步驟反過來就可以理解其中的原因.

Good night.

[Update] boost::decay documentation issue

2010-01-14T09:38:35Z

The issue with boost::decay documentation that I blogged about 10 days ago has been fixed in trunk.

What Should We Teach New Software Developers? Why?

2010-01-04T16:34:23Z

Would you trust someone who had not seen a patient for years to teach surgery? What would you think of a piano teacher who never touched the keyboard? A CS education must bring a student beyond the necessary book learning to a mastery of its application in complete systems and an appreciation of aesthetics in code.

這句話說得真好.

via: What Should We Teach New Software Developers? Why? - Bjarne Stroustrup.

boost::decay documentation issue

2010-01-14T09:37:36Z

前陣子看了 Hubert 的一個 boost::exception 的例子, 猛然注意到自己不確定 boost::decay 的作用.

去看了它的文件, 才發現文件不盡然正確... 已 submit 了一個 ticket 給 Boost, 希望早日修正.

Bit-fu

2010-01-03T13:32:52Z

Did you know, for x is an integer, that -~x yields x + 1 and ~-x yields x - 1?

via: Advanced bit manipulation-fu.

2009 工作回顧

2010-01-03T02:54:26Z

加入現在服務的公司約 20 個月了, 當然不是 (也不可能會) 所有的事情都是令人開心的. Nevertheless, I am glad that I work here. IMHO, 如果要留在台灣認真搞 software R&D 與 engineering, 這裡絕對是最好的環境之一.

在這不到兩年的時間待過兩個 team 擔任技術職 - Project Lead¹, 總共只貢獻少得可憐的幾千 LOC 給我所屬的 team. 反觀上一個工作的職稱是 Senior Technical Manager², 在被 interview 時長官就已經講明公司期待 manager 要寫最多的 code, 當然正式在上海上崗時的確也是如此. 前後兩個工作形成有趣的強烈對比.

20 個月只貢獻幾千行 code 的技術性工作是不是太無聊了 (還是太爽了) ? 一點也不. 比起寫 code, 我花了更多時間在 research, design, review 他人的 design, 幫助別人 review 我的 design, code review, 與 QA co-work 以確保產出的品質, 到 release 後的 defect tracking... 等等.

還記得在面試時 hiring manager 問我 - "你為什麼想加入這間公司?". 我回說 - "朋友告訴我這裡可能是台灣最認真做軟體的公司, 而我想見識這邊的 development process 與體驗這樣的企業文化." And I have to say, I've got what I came for.

以下為廣告...

We are hiring! 我們在找熱愛挑戰的 team player. 如果你需要個能發揮並被 appreciate 的舞台, 請參考上次的廣告. 有興趣的朋友請與我連絡.

名片上中文印的是主任工程師. [↩]
這還是內部職稱, 名片上印的可是更響亮的 business title. [↩]

Another Good Interview Question in C++

2010-01-02T11:46:10Z

elleryq 的這篇 blog post 談到的 ctor (換成 dtor 也一樣) 呼叫 virtual function 狀況 (或說是 problem) 會是很好的 C++ programmer 面試題目. 可在口試時用以窺探 interviewee 對 C++ object model 的了解.

它比公司現行筆試的題目¹ 來得更有深度, 要答得好得清楚知道 vtable 與 vptr 的運作方式. 包含在 construction 與 destruction 時, vptr 的變化.

你知道在這現象背後, 到底發生了什麼事嗎?

base 與 derived 的建構/解構順序 [↩]

一看就知道 – 不 Thread-Safe 的 API

2009-12-01T12:34:21Z

Very well put

當你發現回傳的是一個 char *，又沒有要求你特別 free 他，你是不是就該猜測他是回傳 function 內部的一個 static buffer 了呢？

Via: 從 inet_ntoa 看 thread safe 的 API.

What Happens When We Lie to the Compiler?

2009-11-13T05:30:32Z

When you lie to your compiler, don't be surprised to get results those differ from what you expect.

In this case, the coder promised his/her compiler the value of "value" won't be changed, as it was declared const.

Therefore our best friend (yes, the compiler) who trusted the coder, thought "hey, I could cache this value in a register and not fetch it from RAM every time I reference it", i.e. optimization.

If we change the code in the link slightly, so that function funcC would print *value before the assignment, one would see that the value of *value had actually been modified by function funcA. However, the modification was not visible in main, because the compiler was lied to as the coder explicitly told it that there would be no modification to value.

In the body of function funcC, though value was declared as a pointer to const instance, the compiler was smart enough to know it was lied to. There was a const_cast and a assignment, therefore, the modification to *value was reflected in the output.

Texas Army Base Rampage

2009-11-05T23:15:17Z

我的媽呀~~

在舊金山機場等回台北的飛機, 電視上不斷的播放著德州美軍基地內部發生槍擊的新聞.

CNN 目前的說法是: 連同兇手總共掛了 12 個人, 兇嫌是一名現役中校.

So, You Think C++ is Slower than C

2010-03-15T15:21:14Z

It is true that C++ provides programming constructs those consume more CPU cycles than it would when done without higher level of abstractions. But, hey, that's the cost of abstractions, why pay when they are not needed?

Stop laying out your C++ design like Java. Avoid inheritance when possible. Don't make every member function and destructor virtual without really thinking. They not only increase your run time overhead, they boost the complexity (read coupling) of your code like nothing else.

C++ does every C-style stuff the same way as C does. Not to mention it is capable of more compile time computation than C. I just fail to see how C++ could be slower than C in run time, seriously.

Boost.Lexical-Cast Alternatives

2010-02-12T02:30:34Z

今天稍早, 跟一位同事聊到 Boost 的 lexical_cast. 打開了 Firefox 請出 Google, 想找到能幫助我介紹 lexical_cast 的資源. 意外地, Google 把我帶到讓我賺了介紹獎金, 現在跟我是同事的 Jeff, 談到 lexical_cast 的文章.

在這篇文字的討論串, Jeff 寫道:

我覺得如果可以用這樣的寫法，那就太好了：
uint32_t ID = lexical_cast<auto>("1234567");
甚至最好是：
template <class From, class To = auto>
To lexical_cast(From s) {...}

uint32_t ID = lexical_cast("1234567");
Jeff Hung

小弟既然收了 Jeff 的好處, 當然得回報一下試著幫忙想想辦法:¹

PLAIN TEXT

C++:

#include <sstream>
#include <iostream>
#include <stdexcept>
class lexi_cast
{
public:
template <class Input>
lexi_cast(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast failed");
}
template <class Output>
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast failed");
return out;
}
private:
std::stringstream ss_;
};
int main()
{
using namespace std;
// Converts C-style string to int.
int i = lexi_cast("123");
cout <<i <<endl;
// Converts int to std::string.
string s = lexi_cast(i);
cout <<s <<endl;
return 0;
}

岔題一下.

我一直不是很認同, 在 C++ 中, 以不同的規則來命名 class/function/object. 主要的原因是, 我認為這三者的分野其實並沒有那麼絕對.

上面的 lexi_cast 就是一個很好的例子. 雖然它與 "真正" 的 function 相較仍有細微的不同, 但它的確是設計來讓使用者以 "function 風格" 使用的. 硬是把它的名字取得跟其他 function 格格不入, 豈不是很礙眼? 一個 function-like 的 instance (function instance, class instance or object instance) 可以在一個版本是真的 function, 在下一個版本卻變成 functional object, 甚至是如例中的 class instance.

從另一個方面來看, 如果一個 "正常" class 設計的讓人容易把該 class 本身或所 instantiate 的 object 錯誤地當作 function 使用, 而必須以命名原則來區分, 其設計者更是應該要好好反省.

看起來這似乎已滿足了 Jeff 的基本需求, 只是這全自動的轉換機制也有它的問題. 有些時候, 不提供更多資訊給 compiler, 就是會有 ambiguity. 例如 stream insertion:

PLAIN TEXT

C++:

// Ambigous! This won't compile!
cout <<lexi_cast(some_object);

Output stream 的 operator<< 有很多 overload. 由於 lexi_cast 提供了 generic 的 conversion operator, 因此 compiler 會找到多個可行 (viable) 的 overload. 若我們不顯性提示, compiler 會無法決定到底該採用哪個 overload. 這時候, lexi_cast 的全自動 (或說是缺乏手動指定的) 轉換功能反而變成了一種缺陷.

Attempt number 2. 簡單的把 lexi_cast 改成一個可以指定目的形別的 class template, 並配上做自動轉換的 default template parameter (struct auto_deduce) 以及 specialization:

PLAIN TEXT

C++:

struct auto_deduce {};
template <class Output = auto_deduce>
class lexi_cast2
{
public:
template <class Input>
lexi_cast2(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast2 failed");
}
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast2 failed");
return out;
}
private:
std::stringstream ss_;
};
template <>
class lexi_cast2</*Output =*/auto_deduce>
{
public:
template <class Input>
lexi_cast2(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast2 failed");
}
template <class Output>
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast2 failed");
return out;
}
private:
std::stringstream ss_;
};

效果並不理想. 自動轉換 (default behavior of class template lexi_cast2) 雖不需要指定 type, 但還是需要角括號 (angled bracket), 用起來醜到爆:

PLAIN TEXT

C++:

int main()
{
using namespace std;
// Note the next (commented) line won't compile,
// int i = lexi_cast2("123");
// Angled brackets needed for auto deduction.
// Not pretty at all.
int i = lexi_cast2<>("123");
cout <<i <<endl;
string s = lexi_cast2<>(i);
cout <<s <<endl;
// Now we could specify which "type" to convert to.
cout <<lexi_cast2<int>(s) <<endl;
return 0;
}

Attempt number 3. 下面的程式中的 class template lexi_cast3_helper 與 specialization 是從前面的 lexi_cast2 修改過來的. 只增加了 copy-ctor:²

PLAIN TEXT

C++:

template <class Output>
class lexi_cast3_helper
{
public:
template <class Input>
lexi_cast3_helper(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast3 failed");
}
// Copy-ctor. Needed for compilation, but not
// invoked at run-time.
lexi_cast3_helper(const lexi_cast3_helper& other)
{
ss_ <<other.ss_.str();
}
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast3 failed");
return out;
}
private:
std::stringstream ss_;
};
template <>
class lexi_cast3_helper</*Output =*/auto_deduce>
{
public:
template <class Input>
lexi_cast3_helper(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast3 failed");
}
// Copy-ctor. Needed for compilation, but not
// invoked at run-time.
lexi_cast3_helper(const lexi_cast3_helper& other)
{
ss_ <<other.ss_.str();
}
template <class Output>
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast3 failed");
return out;
}
private:
std::stringstream ss_;
};

把 lexi_cast3_helper 搭配上兩個 function template - 兩個 lexi_cast3 的 overload. 一個用來在自動轉換時躲避角括號 (angled bracket), 另一個讓使用者自行指定轉換的目的形別:

PLAIN TEXT

C++:

// Overload for output type auto deduction.
template <class Input>
lexi_cast3_helper<auto_deduce>
lexi_cast3(const Input& in)
{
return lexi_cast3_helper<auto_deduce>(in);
}
// Overload for user-specified output type.
template <class Output, class Input>
lexi_cast3_helper<Output>
lexi_cast3(const Input& in)
{
return lexi_cast3_helper<Output>(in);
}

結果是:

PLAIN TEXT

C++:

int main()
{
using namespace std;
// No ugly angled brackets for
// auto deduction of output type.
int i = lexi_cast3("123");
cout <<i <<endl;
string s = lexi_cast3(i);
cout <<s <<endl;
// User-specified output type.
cout <<lexi_cast3<int>(s) <<endl;
return 0;
}

這次看來就像樣多了. 能美美地做自動轉換, 也能自行指定轉換的目的形別.

The moral of this post - 果然還是 C++ 好玩!

[Update. Sep 22, 2009]

Improved and simplified. Per Jeff's request:

PLAIN TEXT

C++:

class lexi_cast4_helper
{
public:
template <class Input>
lexi_cast4_helper(const Input& in)
{
ss_ <<in;
if(!ss_.good())
throw std::runtime_error("lexi_cast4 failed");
}
// Copy-ctor. Needed for compilation, but not
// invoked at run-time.
lexi_cast4_helper(const lexi_cast4_helper& other)
{
ss_ <<other.ss_.str();
}
template <class Output>
operator Output()
{
Output out;
ss_>> out;
if(ss_.bad() || ss_.fail())
throw std::runtime_error("lexi_cast4 failed");
return out;
}
private:
std::stringstream ss_;
};
// Overload for output type auto deduction.
template <class Input>
lexi_cast4_helper lexi_cast4(const Input& in)
{
return lexi_cast4_helper(in);
}
// Overload for user-specified output type.
// Instead of returning conversion helper,
// this version returns output type.
template <class Output, class Input>
Output lexi_cast4(const Input& in)
{
return lexi_cast4_helper(in);
}

Sorry, Jeff. 明明是我自己愛玩卻還要遷拖到你. [↩]
由於 IOStream 是不能 copy 的, 因此 lexi_cast3_helper 需要有 copy-ctor 才能 compile. 有趣的是, 因為 RVO 的關係, 這些 copy-ctor 根本沒有 run-time 的用處, 不會被執行到. 可以把它的內容 comment 掉, 甚至亂改, 只要能 compile & link, 仍舊會正常運作. [↩]

Server side connection/session lingering

2009-08-17T02:45:07Z

A great read on how to properly teardown a connection of synchronous protocols (e.g. HTTP) on the server side.

via: SO_LINGER is not the same as Apache's "lingering close".