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

Listing-1.

PLAIN TEXT

C++:

1. using namespace std;
2. T* new_t_nothrow()
3. {
4.   return new (nothrow) T;
5. }

(more...)

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

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

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

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

續自 Exception Handling 新思維.

Preface

取材來說明如何以某種技巧寫出俱備特定目的的 code 有時不是一件容易的事. 我讀過好幾本這樣的 programming 書籍, 即便書中用了不小的篇幅來說明範例相關的 domain/business logic, 可是我依然無法感同身受 (當然也有可能是我太笨). 但當要說明的目的是 exception safety, 那就簡單多了. 以最多 C++ programmer 熟悉的 STL 為例, 應該不會錯到哪裡去.

本文選的題目是 STL 的 uninitialized_fill_n. 雖然這個題目可能同時也是不錯的 template programming 教材, 但是為了避免失焦, 這篇文字將假設讀者對文中使用到的 template programming 技巧以及 STL 有足夠的熟悉度, 並略過部份與 exception safety 無關的細節. 另外, 為方便排版, 文中 code snippet (代碼片斷) 可能不同於引用的來源, 兩者在文中的 context 應為等效.

這篇文字要從 library implementor 的角度出發, 拿 STL 當題材, 探討不同手法的 implementation 俱備的特性.
(more...)

New mind set

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

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

Quote from Google C++ Style Guide:

We do not use C++ exceptions.

在極端狀況下, 我能夠想像在 no virtual function 或是 no templates 但仍能使用 STL 的環境寫 C++. 但完全禁止 user-defined classes/functions 以拋出 exception 的方式回報錯誤的環境呢? No, thanks. 即便有免費的食物與漂亮的辦公室, 這還是太折磨人了.
(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...)