COdE fr3@K

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

2009-11-05T23:00:41Z

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".

The C++0x “Remove Concepts” Decision

2009-08-12T12:52:37Z

懶人包 + Bjarne on DDJ (翻譯), from Paramecium.

Great job! Thanks, Keiko.

Avoid Leading Underscores

2009-07-25T10:08:11Z

在很多 code base 裏面都能看到在前面加個 underscore (底線/下滑线) 的 function/macro/variable. 常常是用來暗示某個 name 是 local/private, 有時是用來避免 name collision.

GoF 的經典巨著 Design Patterns 裏面, 以及一個時期的 Herb Sutter (the GURU), 都以在前面加上底線的方式標示 member data.

所有我見過的 Standard Library 的 implementation 不但都以在前面加個 underscore (底線/下滑线) 的方式命名 inclusion guard,¹ 也多用這方法替 member data 以及非公開的 identifier 起名字. Windows 則更是出了名的有許多在前面加了個 underscore 的標準 (documented) Win32 API.

可是關於 leading underscore, 標準是這麼說的: ²

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

所有以 underscore 起頭的 identifier 都是保留給 compiler/standard library 實作任意使用的. 也就是說如果使用者自行定義了這樣的 identifier, 結果是無法預期的. 運氣好, 在 compile 時就得到 compiler error. 倒楣的話 undefined behavior 也不是不可能發生.

在實踐上, 這樣的 code 有很大的機會可以在你現在使用的 compiler 之下能正常編譯與運作, 但卻不能保證它就能在另一個 compiler (甚至是同一 compiler 的下一個版本) 之下也會得到相同的結果.³

日蝕

2009-07-22T03:54:39Z

老婆被我叫起床拍的照片.

C++0x – Concepts Rejected

2009-07-21T02:45:59Z

大件事, Concepts 被否決了.

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 的巨浪就要來了, 你準備好了嗎?