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

GION is a project I recently created as a part of my effort towards cleaning-up some of the not-so-pretty and strengthening exception safety of the project code base at work.

It’s released under one of the most permissive FOSS licenses I know of, MIT license, in hope, would help others to write better C++ more easily.

Feedback welcomed.

From Sutter’s Mill:

… we already had a nearly-complete C++0x internal working draft — most features that will be part of C++0x had already been “checked in.” Only a few were still waiting to become stable enough to vote in, including initializer lists, range-based for loops, and concepts.

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

前一陣子花了些時間寫一個 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…)

見過不少 C/C++ Standard Library 的不愛用者. 要辨認他們並不困難, 從 code 中可以很容易發現:

1. 在 header file 以 #pragma once 替代標準 inclusion guard 手法
2. 將一個 const long* 宣告為 CONST LPLONG
3. 習慣性使用 ZeroMemory/bzero 與 CopyMemory/bcopy, 而 (無意間?) 迴避 memset 與 memcpy 等標準 API

除了省去替 inclusion guard 取有效 (唯一) 名字的功夫之外, 我實在是看不出上述習慣有任何實質上的好處.
(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…)

昨天在網上閒逛, 在樂多上看到篇名為 “Socket Programming in C 常犯的錯誤” 的短文. 這短文作者的動機很好, 指出常見到的錯誤並提供個人看法與可能較好的作法. 這樣的行為很值得鼓勵. 但極可惜的是, 結果卻是很不理想的. 容我說句重話, 如果是考試的話該文是得不到我的分數的.
(more…)