New mind set

一直以來 exception handling 與 exception safety 就是 C++ 最重要的課題之一. 正確的 exception handling 真的不是一件跟吃蛋糕一樣容易的事.

但, 它是否一定如此困難, 以致於 只有語言專家才能搞得定? 我認為這與事實相去甚遠.
(more…)

前一陣子花了些時間寫一個 allocator library. 首要目標就是要能符合 C++ Standard 對 allocator 定義的 requirement. 當然也要相容於 Standard C++ Library 的 container 實作, 能與所有的 container function 正確的 inter-operate. 在這個過程中, 我意外地一腳踏進又一個 C++ 的陰暗角落.

先讓我把這個有點嚇人的結論寫在前面:

你所使用的標準 container , 很可能無法完全正確地與 object-stateful 的 allocator 一起運作. 即便該 allocator 確實是符合標準規範的.

不過先別慌. 只要拿來與 container 搭配使用的是沒有 per instance 狀態的 allocator, 你就不會遭遇本文所討論的問題.

(more…)

假設我們需要按照順序以紙條對 Alice 與 Bob 打招呼:

void Alice(string& message_to_alice);
void Bob(const string& message_to_bob);

(more…)

Abrahams Guarantees

在 C++ 的世界裡, 正確的 exception handling 是專業的 C++ programmer 不可或缺的技巧. 雖然它的概念並不困難, 但實作起來卻常不見得那麼容易.

要做到正確的 exception handling, 首先必須要了解什麼是 exception safety. 一個需要與 exception 打交道的 component 可在其介面實作人稱 Abrahams guarantees 的三種 exception safety 保證之一:

1. The basic guarantee

允許操作失敗時改變物件的狀態, 但不能有 resource leak. 且該物件的狀態必須是可靠的仍然可以被解構, 操作失敗後該物件的狀態可以是不完全能被預測的.

2. The strong guarantee

操作後的狀態只能是成功完成, 或是將該物件回復到操作之前的狀態並拋出一個 exception.

3. The no-throw guarantee

操作不會拋出 exception.

(more…)

去年我寫過一篇文章, 大意是在說 大多數人所使用的 Singleton 實作都是有問題的. 在文章靠近後面的部份, 我也介紹了一種較少為人知, 我常用在 lifetime 是全局但 scope 是局部的 (global) 變數的 Singleton 實作. 雖然這實作離 fool proof 還差得遠, 在使用者能夠正確地 include header 的情況下, 它可能已經是最接近 bullet proof 的實作了.

“好吧, 那我就用類似你的 Singleton 實作總行了吧!?” 先別急著動手改 code, 實作是容易更換的, 但使用 Singleton Pattern 的原因卻與更重要的介面, 甚至架構的設計思維息息相關. 工作的實務經驗以及本身的興趣研究讓我體會到, 大多數的情況下 Singleton 的使用是可以避免的. 在這些非必要情況卻依然採用 Singleton 的原因常是:

• 沒把問題想清楚
• 好玩
• 因為有個叫作 Singleton 的 pattern

(more…)

我知道很多人一直是這樣做的, 可是我從沒搞懂為什麼在 windows 平台上, 用上了 _TCHAR, _TEXT 再 define 個 _UNICODE. 或是用上了 whar_t 與 std::wstring. 就能算是 Unicode 化的程式?
(more…)

最近被我面試的十來位應徵者, 除了一位之外, 都不清楚以下兩個 pointer to NULL (指向 0 的指標) 的基本特性:

• delete 一個指向 NULL 的指標是安全的
• 以一個指向 NULL 的 C-style 字串為參數呼叫 strlen 會造成死機 (segmentation fault, access violation or whatever)

(more…)

接續兩個多禮拜前, 那篇 囉唆的開場…

話說那天面試 A 君作答最後一題的過程中, 或許是 A 君作答的速度慢了. 突然想到自己沒有用過真實世界的例子仔細檢驗過我所謂好方法. 面試後想像了幾個狀況, 我的 C++ 世界開始出現烏雲…
(more…)

周五下午在新上任的工作進行了第一次面試. 被面試的這位應徵者 (就稱為 A 君吧) 已有三年以上在工作上使用 C++ 的經驗, 對自己的 C++ 能力的評比給的是熟悉 (還沒到精通) . 在聊了可能一個鐘頭左右後, 他表示自己寫程式很少發生 memory leak, 卻又舉例不出具體作法, 只表示這是經驗與習慣使然. 針對這點, 我在白板上出了個題目:

class foo {};
class bar
{
  foo* fp_;
public:
  bar(foo* fp)
  : fp_(fp)
  {
    // ....
  }
  ~bar()
  {
    delete fp_;
  }
};

bar* create_bar()
{
  foo* fp = new foo;
  return new bar(fp);
}

假設你是負責維護 create_bar 的 programmer. 並且, 呼叫 create_bar 的使用者一定會記得 delete 掉被該 function new 出來的 instance . 請問 create_bar 這個函數有沒有潛在的 leak? 如果有, 可以如何改善?

(more…)

最近一些朋友在我這邊留言, 貼出來的結果常常不如預期. 我也是過來人, 很清楚他們雖然都是 programmer, 但其實對 HTML 並不熟悉. 就跟我一開始寫這個 blog 的時候一樣. 現在的我當然比以前好多了, 勉強還有一兩樣東西可以拿出來與其他人分享.
(more…)