COdE fr3@K

“A Brief Introduction to C++11″ Slidedeck

2012-04-29T16:21:05Z

早上在 OSDC.TW 分享的 A Brief Introduction to C++11 投影片.

“A Brief Introduction to C++11″ Slidedeck was first posted on April 15, 2012 at 11:03 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Why is Force Killing Threads a Bad Idea?

2012-04-29T16:36:12Z

“把類似 monit 這樣的 watchdog 機制用在 worker threads 上或許是個好主意.” 前陣子同事在聊天的時候跟我提起這樣的想法.

“我們可以做一個 watchdog thread, 並且讓每個 worker thread 定期向 watchdog 打 heartbeat.” 他向我進一步說明.

“這樣當其中有 worker 出錯, 沒反應, 以及進入死循環的時候我們就可以把它幹掉, 或許還可以重起.” 同事愈說愈起勁.

乍聽之下這很合理, 畢竟類似的事情我們已經對 process (monit) 以及 host OS 本身^[1] 做了許久. 只可惜, 實務上把類似的機制套在 thread 身上非常困難, 甚至是完全不可行. 原因是 thread 與 process 有許多不同. 特別是在 resource isolation 方面.

pthread_cancel(3)

PTHREAD_CANCEL_ASYNCHRONOUS

TerminateThread()

類似但不完全相同的問題

同一個 process 內的各個 thread 的 memory space 是共同擁有的, 也就是說除了 thread local storage 與 per-thread call stack 之外的所有 resource 幾乎都是不分你我共享的. 正因為這個你泥中有我我泥中有你, 個別的 thread 無法提供如 process 結束時的自動資源回收機制.^[2] 換句話說, 如果有個 thread 在來不及 release 已被 allocate 的 resource 時候就被幹掉, 這個 resource 就被 leak 掉了, 直到 process 結束.

的確, 只要狀況不嚴重^[3], resource leak 並不一定是太糟糕的事情. 可是狀態的不一致 (state inconsistency) 就不一樣了, 後者很容易造成災難. 假設被暴力幹掉的 thread 正 hold 住一個 mutex, 接下來很可能其他的 thread 都將面對被 deadlock 的命運. 也許有人會說, “這不是問題, 我們的 thread 之間不需要同步沒有用到 mutex.”

只是, 可能不是每個人都清楚的是 – 很多 library/module 都需要同步! 例如 syslog(), printf()/fprintf() 與 malloc()/free() 等直接間接都容易被使用到的 function.

除了使用的全部是自己最小心寫的 code 之外, 我們怎麼能確定被暴力幹掉的 thread 不是正跑在前述的 function 裏面? 又或不會正在執行 critical section 的 code? 這等於是要求整個程式都要符合 async-signal-safe 的要求. 相信我, 你不會希望走上這條路的 XD

結論 – 暴力停止一個正在運行的 thread 很難避免不理想的結果, 輕則 resource leak, 嚴重時可 deadlock 整個程式, 甚至因狀態的不一致而導致其他無法預測的行為.

延伸討論 – fork 一個跑了多個 thread 的 process 會有什麼後果? 提示: 只有 forking thread 會在 child process 繼續跑.

如 Linux 的 watchdog(8).
如回收 fd, 釋放記憶體等等.
在我看來, 如果 leak 的只是 memory 而 size 與次數都小, 不見得是不能接受的狀況.

Why is Force Killing Threads a Bad Idea? was first posted on March 5, 2012 at 12:15 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Root of All Evil – Defining Variables Early

2010-11-19T14:07:58Z

Before we dive into the topic of this post, I would like to share with you the best possible advise I could ever give – never do everything by the book.

I know it sounds kinda odd and may appear to be irresponsible. After all, this series is about what to avoid and promote best practice. Am I not asking you do what I tell you? No, I am not.

I am asking you to think and to reason consciously why you chose to code something the way you did.

In the first post of this series, I wrote about how returning early improves code readability. It may appear so in the code snip presented in the post. It may seem to be appropriate in scenarios off the top of your head. However, I am most certain that there are contexts where returning early actually does the opposite – hurting code readability.

It is important that we understand a best practice is anything but the law. When circumstances change, it may not stand.

I ask you to think as you code.

Now, back to the topic. In this post, we will revisit a well known best practice from a less discussed perspective.

It is almost always a good practice to define variables where they are first needed, but not earlier. Doing otherwise is almost certainly asking for trouble. Take this WinMain() function from Miranda IM for example, and fast forward to line 649, the first line of interest of this post:

        CreateServiceFunction(MS_SYSTEM_SETIDLECALLBACK,SystemSetIdleCallback);
        CreateServiceFunction(MS_SYSTEM_GETIDLE, SystemGetIdle);
        dwEventTime=GetTickCount();
        myPid=GetCurrentProcessId();
        for(;messageloop;) {
                MSG msg;
                DWORD rc;
                BOOL dying=FALSE;
                rc=MsgWaitForMultipleObjectsExWorkaround(waitObjectCount, hWaitObjects, INFINITE, QS_ALLINPUT, MWMO_ALERTABLE);

It is a for statement using the variable messageloop as its condition.

Depending on your preference to trace code forwards or backwards, visit Miranda IM’s source browser via either link, and try answering this – what are the possible values of messageloop when the for loop starts?

Before we go on, please allow yourself a minute or two to go through the code and find out the answer.

Okay, now that we know the variable messageloop was defined at line 546 as int with the value 1 at the beginning of WinMain().

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, int )
{
        DWORD myPid=0;
        int messageloop=1;
        HMODULE hUser32, hThemeAPI, hDwmApi, hShFolder = NULL;

And as it turns out, messageloop was never modified, in fact, it was never referenced elsewhere, except at line 649, as the condition of said for statement. That’s more than 100 LOC (lines of code) apart, and nothing relevant in between.

I don’t know about you, but I think it is pure annoying to make people going through more than a few LOC, and end up learning there was nothing of interest, it is a major waste of time and one of the best ways to upset people.

Mayers has been telling us to postpone variable definitions as long as possible for more than a decade. If you are not convinced by the book for whatever reason, think code readability, and make the lives of your fellow code readers easier.

One day, that reader of your code may very well be you.

Root of All Evil – Defining Variables Early was first posted on November 7, 2010 at 11:05 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Function overloading by return type

2012-01-14T12:19:53Z

A very interesting and informative answer on Stack Overflow.

Note in the end of the post, author of the answer presented a trick demonstrating how one could overload functions by return type. Coincidentally, a similar hack had been shown in an earlier post of mine.

One more example why you shouldn’t insist on using different naming schemes to name classes from functions consistently.

Hey, sometimes, objects are functions and functions are objects.^[1]

Some other times, objects could be functions and classes could be objects.

Function overloading by return type was first posted on November 2, 2010 at 12:07 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Root of All Evil – Nasty If Else blocks

2010-11-19T16:22:52Z

It has been a while since I last wrote. It is not that I wrote enough, I still love it, and am keen to share my (possibly biased) thoughts with fellow developers out there. But life and work have kept me busy in the past few months, busier than I would like to be.

Anyhow, I am starting a series of posts called “Root of All Evil”. The plan is to write about bad practices I see at work, on the Internet, and smelly code I used to write. I hope to be able to cover the following aspects:

What does bad code look like
Why is it bad
And how it could be improved/refactored

If you happen to care reading my blog, chances are you won’t be contributing too many of those. However, even if they were someone else’s responsibility, ~~it is essential that you~~ I encourage you to step up, and talk him/her into making necessary changes and quitting the habit, perhaps over a cup of coffee or via a formal code review.

Though it is unlikely that I would have the luxury and the time to write weekly as I used to, I will just do my best. This series will be written casually, in Chinese or in English, yes, depending on my mood. So, bear with me and here it goes.

Nasty If Else blocks are killers to code readability, and if I may, a huge pain in the ass for sorry developers who ended up maintaining them. They waste your valuable time and energy, deciphering logics that would had otherwise been trivial to understand.

Not so sure? Take the following random code snip taken from the Internet for example:

    void remove(TreapNode *&t, KeyType v)
    {
        if (t == NULL) return;
        if (v > t->key) remove(t->right, v);
        else if (v < t->key) remove(t->left, v);
        else
        {
            if(t->left == NULL && t->right == NULL)
            {
                delete t;
                t = NULL;
            }
            else if(t->left == NULL)
            {
                TreapNode *tmp = t;
                t = t->right;
                delete tmp;
            }
            else if(t->right == NULL)
            {
                TreapNode *tmp = t;
                t = t->left;
                delete tmp;
            }
            else
            {
                if (t->left->priority < t->right->priority)
                {
                    RotateLeft(t);
                    remove(t->left, v);
                }
                else
                {
                    RotateRight(t);
                    remove(t->right, v);
                }
            }
        }
    }

Note: Please don’t get into what it does, and quite frankly, I don’t care. Not for the purpose of this post anyway. I personally find it fascinating that, oftentimes, one could improve a piece of code without understanding what it actually does.

Can you tell what goes after the recursive remove() if the condition in line 4 was true?

Of course you can. Nothing, it just returns.

But how long did it take you to find that out? Was it easy to you to skim through the entire function and at the same time, keeping track of levels of if/else blocks?

Only if it had been written differently, possibly in the line of the following:

    void remove(TreapNode *&t, KeyType v)
    {
        if (t == NULL)
          return;

        if (v > t->key)
        {
          remove(t->right, v);
          return;
        }

        if (v < t->key)
        {
          remove(t->left, v);
          return;
        }

        // snipped...
    }

It is now obvious. Any one could tell in 3 seconds. And better yet, without reading the remaining of the function.

Dealing with one such badly written function may be trivial, but digging through 10, 20 of these in a large code base may become stressful as complexity adds up.

To avoid nasty if/else blocks and improve readability, return as early as possible and use Extract Method when appropriate.

Trust me, maintainers of your code will appreciate it.

Root of All Evil – Nasty If Else blocks was first posted on October 31, 2010 at 5:18 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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

2010-08-25T14:38:23Z

Hi Sam,

你的留言讓我想了許久. 小弟以為, 原創的繁中技術文字過少的最大關鍵不在於書籍市場, 而在寫的動機. 只要找到非金錢回報的動機, 就能寫得下去. 畢竟, 這是個屬於網路的年代, 只要有心有料, 甚至只要自 high, 誰都可以發表.

我們都在這片土地上生活, 在這個業界燃燒熱血, 盼望能實現自己的夢想. 以我為例, 我的夢想是台灣能有個健康前瞻有搞頭的軟體產業. 讓我們不一定要離鄉背井, 才能夠免去賣肝的宿命, 可以好好賣腦揮撒我們的熱情展現我們的專業, 並且得到適當的回報.

我很清楚, 在這個大環境, 我的想法多少不太現實. 即便如此, 除了抱怨, 我還選擇盡一點微薄的力量. 這個部落格能還能活著, 最大的動力正是對這個夢想的執著.

你的夢想是什麼?

[後記] 這篇文字是在抒發我的牢騷, 非針對個人. Sam, 不好意思借用了你的名字…

Re: 你怎麼在看簡體的東西!? was first posted on August 8, 2010 at 11:54 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Did You Know, “new (nothrow) T” Throws?

2010-08-05T15:07:17Z

可能會出乎不少人的意料, 下面的 code snip 可能會拋出 exception.

Listing-1.

using namespace std;
T* new_t_nothrow()
{
  return new (nothrow) T;
}

許多人都知道, 這樣的 new expression (nothrow new) 的做動可分成兩個部份:

首先根據 sizeof(T) 的大小呼叫 nothrow 的 operator new 以取得將被創建於 heap 上的 T 物件的 memory footprint
然後再對該 memory 位置做 T 的 placement new

也可以說, 它與下面的 code 等效：

Listing-2.

T* new_t_nothrow()
{
  // For the purpose of this discussion, one can freely
  // exchange the following invocation of `operator new`
  // (in line 6) with `malloc(sizeof(T))`.
  char* buf = operator new (sizeof(T), nothrow);
  if(buf == NULL)
    return NULL;

  try
  {
    // Invoke `T::T()` at the address pointed by `buf`.
    return new (buf) T;
  }
  catch(...)
  {
    operator delete (buf);
    throw;
  }
}

看到這裡, 相信大部份的朋友已經瞧出端倪來了. Listing 1 的 new expression (或是 listing 2 的第 13 行) 會拋出 exception 一點也不奇怪, 全看 T 的 definition. 若 T 的定義為下列任何一種 (note: not a complete listing), 則 new (nothrow) T 依然可能觸發 exception:

Listing-3.

struct T1
{
  T1() { throw exception(); }
};
struct T2
{
  T2() { string tmp("blah blah"); }
};
struct T3
{
  U* u;
  T3() : u(new U) {}
};
struct T4 : Tx // Tx: any one of T1, T2, T3 ...
{};
struct T5
{
  Tx member;
};
struct T6
{
  T6() { Tx tmp; }
};

換一個說法, 如果在 stack 上 instantiate class T 的物件可能會導致 exception, 那以 nothrow new 創建也是一樣的狀況:

Listing-4.

void foo
{
  // If instantiating an object of `class T` on the stack
  // could throw,
  T t;

  // then instantiating it via `nothrow new` could, too.
  T* p = new (nothrow) T;
}

Nothrow new 所避掉的 exception 只不過是在請求 object 所需的 memory footprint 時所可能引起的 exception, 但不會改變 object 被創建時的行為. 創建中的 object 直接或間接做的事情仍然可能觸發 exception. 而那最外層的 new (nothrow) T 只會增加正確錯誤處理的複雜度 – client 既需要 handle NULL 也要考慮 exception 發生的情況.

Did You Know, “new (nothrow) T” Throws? was first posted on August 1, 2010 at 8:08 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

You Don’t Have to Resort to Goto

2011-11-29T10:13:20Z

你一定看過這樣的 code:

int do_work(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:

int do_work(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:

int do_work(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:

static int do_work_using_client_buffer(char* buf, n)
{
  if(do_foo(buf, n) != OKAY)
    return ERROR;

  if(do_bar(buf, n) != OKAY)
    return ERROR;

  return OKAY;
}

int do_work(size_t n)
{
  int result;
  char* buf;

  if(n == 0)
    return ERROR;

  buf =  malloc(n);
  if(buf == 0)
    return ERROR;

  result = do_work_helper(buf, n);

  free(buf);
  return result;
}

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

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

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

Edit:

do_something() -> do_work()
do_something_helper() -> do_work_using_client_buffer()

You Don’t Have to Resort to Goto was first posted on June 19, 2010 at 10:35 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

華碩品質, 以卵擊石

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.

華碩品質, 以卵擊石 was first posted on June 2, 2010 at 1:24 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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

2010-05-30T13:17:14Z

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

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

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

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

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

你怎麼在看簡體的東西!? was first posted on May 30, 2010 at 4:31 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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.

re: 解读google C++ code style谈对C++的理解 was first posted on May 30, 2010 at 4:11 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

後方, 起浪了

2010-05-06T07:59:52Z

後方的浪.

後方, 起浪了 was first posted on May 4, 2010 at 11:54 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Pic of starryalley on iThome

2010-03-23T16:35:57Z

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

Pic of starryalley on iThome was first posted on March 24, 2010 at 12:35 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

Quiz on C++ Object Model

2010-03-13T09:58:27Z

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

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

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

Quiz on C++ Object Model was first posted on March 4, 2010 at 12:07 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

當 Constructor 遇上 Virtual Function

2010-03-03T02:24:45Z

Background

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

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.

當 Constructor 遇上 Virtual Function was first posted on March 3, 2010 at 12:19 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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

[Update] boost::decay documentation issue was first posted on January 14, 2010 at 5:35 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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.

What Should We Teach New Software Developers? Why? was first posted on January 5, 2010 at 12:29 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

boost::decay documentation issue

2010-01-14T09:37:36Z

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

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

boost::decay documentation issue was first posted on January 4, 2010 at 8:48 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

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.

Bit-fu was first posted on January 3, 2010 at 11:40 am.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org

2009 工作回顧

2010-01-03T02:54:26Z

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

在這不到兩年的時間待過兩個 team 擔任技術職 – Project Lead^[1], 總共只貢獻少得可憐的幾千 LOC 給我所屬的 team. 反觀上一個工作的職稱是 Senior Technical Manager^[2], 在被 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.

2009 工作回顧 was first posted on January 2, 2010 at 6:35 pm.
©2012 "COdE fr3@K". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at freak@fsfoundry.org