昨天晚上和同事討論寫 Log 的問題，談到寫到文件，后來談到寫文件用 ReadFile、WriteFile 還是用 fread、fwrite 的問題。我一直對 fread、fwrite 沒啥好感，原因是它自作主張的搞了一套緩存機制?？墒莾H僅這點就鄙視它似乎還說不過去。談著談著，后來我們對它的參數設計起了懷疑——這里有一個參數是多余的！從表面看，ReadFile、WriteFile 的參數是恰到好處的，fread、fwrite 作為它們的上層函數，似乎沒必要把一個參數拆成 2 個呀。

后來就一直跟 fread，直到出現 ReadFile，都沒發現這 2 個參數有什么特別的用處，他們很早就被乘起來了：

count = total = elementSize * count;

所以，目前我仍然對這個設計感到困惑。

有誰知道，這是由于什么樣的歷史原因/技術原因，才使這個函數變成現在這副模樣的？

我原先不喜歡加 Log，后來我的頭兒希望加 Log，于是乎我手頭的項目就全是 Log 了。之前一直是定義一個不定參數的宏或者函數，遇到需要的地方就 LOG(...)。后來越來越感覺對于函數進出的信息比較渴求，于是弄了個固定的 LOG_FUNCTION() 來記錄函數進入，因為有 __FUNCTION__ 嘛。

對于函數出口，原先一直是手寫的，剛剛前幾天在這里討論的資源釋放問題讓我學到了新的解決方法——使用類似 Loki::ScopeGuard 的機制來輸出函數退出。

晚上重新寫了一下。見 http://code.google.com/p/xllog/。

使用如下：

void bar()
{
    XL_LOG_FUNCTION();
    XL_LOG(L"%s\n", L"In function bar.");
}

void foo()
{
    XL_LOG_FUNCTION();
    XL_LOG(L"%s\n", L"In function foo.");

    bar();
}

int main()
{
    XL_LOG_FUNCTION();

    foo();

    return 0;
}


運行結果：

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Enter Function main
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Enter Function foo
In function foo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Enter Function bar
In function bar.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Leave Function bar
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Leave Function foo
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Leave Function main

基本功能我自己已經可以接受了。

有兩點我想改進的，不知道能不能實現：

1、每個用到的函數寫一句 XL_LOG_FUNCTION() 太麻煩了，而且有可能被用戶寫到任意地方，而非函數開始。有沒有一種機制，使得可以寫成類似（要保持函數定義的形式，不要把函數名括號括起來）：

void __log foo()
{
}

從而被展開成：

void foo()
{
    XL_LOG_FUNCTION();
}

呢？

或者有沒有一種方法可以不用寫任何東西就讓每個函數體自動加上這么一句呢？

2、我想記錄函數的調用層次。如果上面行能夠實現的話，就沒問題了，我可以自己記錄函數進出次數。如果不能，那么依靠用戶寫 XL_LOG_FUNCTION() 來記錄就不可靠了。有沒有類似 __CALL_STACK_DEPTH__ 的預定義宏呢？

最后還有一個實際問題。實際使用中，在寫代碼的時候可能無法確定所寫部位到底是偏底層還是偏上層。如果太偏底層而打了 Log，會輸出很多 Log 干擾分析；如果太高層的而沒打 Log，有可能遇到問題信息不足。這個問題該如何解決好呢？大家有沒有成熟的解決思路呢？

最近有個東西，需要讀 XML 配置文件，于是用 msxml 做了。msxml 是基于 COM 的，使用之前需要 CoInitialize，使用之后需要 CoUninitialize。于是我寫成了：

void foo()
{
    CoInitialize(NULL);

    // Reading configuration

    CoUninitialize();
}

剛才我正樂此不彼的把類似這樣的東西改成：

void foo()
{
    CoInitialize(NULL);
    LOKI_ON_BLOCK_EXIT(CoUninitialize);

    // Reading configuration
}

前面的同事過來看到了，說，你不該在這里調用 CoInitialize 和 CoUninitialize。如果有的地方也在用 COM，你這里 CoUninitialize 一下，別的地方就會出錯了，上次的某個 Bug 就是。

我狡辯道：我假定這里沒有多線程環境（實際上也是），并且約定別的地方用 COM 的時候調用 CoInitialize 時不要判斷返回值。

同事：應該和大眾習慣保持一致，最好就是全項目最開始的時候 CoInitialize 一次，結束的時候 CoUninitialize 一次。

我：我這里是較底層功能函數。

同事：可以以文檔的方式注明，使用該模塊前必須自己 CoInitialize，使用完畢后自己 CoUninitialize。

我：我只是想要用起來方便一點，用的時候不要有那么多先決條件和后置條件。再說，人家本來可以不知道我用了 COM，我這么一說明，就暴露了內部信息了不是？

其實我被動搖了。

各位大大，你們怎么處理呢？

------------------------------華麗的分割線（13:27 p.m. 增加）----------------------------------

好，既然 CoInitialize 和 CoUninitialize 有引用計數機制，那么這個具體問題已經解決。

那么，有沒有類似的成對使用的 API，會對進程全局產生影響的呢？如果有，在底層要用到的時候該怎么處理？

如題。

沒有界面、不帶任何文檔的軟件怎么辦？

先看一個例子。首先，我要寫一個vector；其次，為了使用方便，我需要提供一個帶 size 參數的構造函數。要求就這兩點。

那么，勢必要：

class vector
{
public:
    vector(size_t size)
    {
        // ...
        m_pData = new int[size]; // 假設就是 int 這樣的基本類型好了，以避免下面可能出現的離題
        // ...
    }
};

問題來了。new 不是有可能失敗嗎？失敗了在老編譯器里會返回 NULL（這個情形也先無視），在新編譯器里會拋異常。那么，在這里要不要進行檢查呢？如果檢查：

try
{
    m_pData = new int[size];
}
catch (...)
{

}

catch到了。那么在這里可以干啥呢？似乎。。。啥也干不了！作為構造函數，沒法使用返回值，自然只能使用異常來提示外界；既然本來就是異常，我又何必在這里 try 一次呢？（假設這里沒有其他錯誤要處理，也假設這里的類型是int之類的基本類型，不會出現執行元素的構造函數失敗的情形）

既然這里的 try 讓我們如此無奈，那么就不必 try 了。這個時候，我需要給 vector(size_t size) 標記上 throw 嗎？如果不標記，使用者怎么知道這里可能會有異常？如果標記了，或者沒標記但使用者意識到了，那么他會這樣用：

try
{
    vector v(10);
    // Task with v
    // ...
    // ...
    // ...
}
catch (...)
{
    // Error handler
}

因為 v 的作用域被限制在了 try 內，所以所有的與 v 相關的邏輯代碼全部要放在 try 內部了。這種樣子似乎與 C# 很像！在 C# 里，try...catch... 是標準的做法；但是在 C++ 里，似乎不會如此經常地用 try catch，要不然，為什么我見過的 C++ 代碼都不是這樣子的呢？兩年前在金山實習的時候，有一次我把 try...catch 當做通用的錯誤處理來做，所有的錯誤都搞成一種異常，返回值僅返回正常值。結果董波叔叔說，這樣子是不對滴，但是沒給出讓我信服理由，可能就是，C++ 的 try...catch 的性能很不好之類的。（C# 以及 Java 的 try...catch 的性能好嗎？）

好，既然大家都不這么辦，是不是這里也不用 try 了？于是，內存分配錯誤就讓它自生自滅了……記得以前某本書上看到，說這種情形下的處理，僅僅是一個道德問題而已。真的無解嗎？

如果放寬要求，不要求在構造函數提供內存分配，那倒是有一種解法——分兩階段構造：

class vector
{
public:
    vector()
    {
        // ...
    }
    bool allocate(size_t size)
    {
        try
        {
            m_pData = new int[size];
        }
        catch (...)
        {
            return false;
        }
        if (m_pData == NULL)
        {
            return false;
        }
        // Other code ...
        return true;
    }
};

但是使用起來就不“方便”了。現實中，這種情形倒是存在，如 CWindow 的 Create，還有啥啥啥的 Init 等等。

真的沒有辦法兼顧方便與安全嗎？