續自 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…)

From Sutter’s Mill:

… The main trouble with Systems Hungarian comes from trying to embed information about a variable’s type into the variable’s name by prepending an encoded wart like the venerable sz, pach, ul, and their ilk. Although potentially helpful in a weakly-typed language like C, that’s known to be brittle and the prefixes tend to turn into lies as variable types morph during maintenance. The warting systems also don’t extend well to user-defined types and templates.

I am glad to learn that the Guru and I share similar views on this matter.

Further readings:

• Hugarian notation - it’s my turn now from Larry Osterman’s WebLog.
• Die, Hungarian notation… Just *die* from Neopoleon.
• Making Wrong Code Look Wrong from Joel on Software.

New mind set

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

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

Some of my friends use iGoogle as a portal for handling daily office routines. They had been selling me the solution for a while. They were able to get me to give iGoogle a test drive a few weeks ago.
(more…)