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

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

count = total = elementSize * count;

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

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

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

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

晚上重新寫了一下。見 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;
}


運行結(jié)果：

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

基本功能我自己已經(jīng)可以接受了。

有兩點我想改進的，不知道能不能實現(xiàn)：

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

void __log foo()
{
}

從而被展開成：

void foo()
{
    XL_LOG_FUNCTION();
}

呢？

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

2、我想記錄函數(shù)的調(diào)用層次。如果上面行能夠?qū)崿F(xiàn)的話，就沒問題了，我可以自己記錄函數(shù)進出次數(shù)。如果不能，那么依靠用戶寫 XL_LOG_FUNCTION() 來記錄就不可靠了。有沒有類似 __CALL_STACK_DEPTH__ 的預(yù)定義宏呢？

最后還有一個實際問題。實際使用中，在寫代碼的時候可能無法確定所寫部位到底是偏底層還是偏上層。如果太偏底層而打了 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
}

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

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

同事：應(yīng)該和大眾習(xí)慣保持一致，最好就是全項目最開始的時候 CoInitialize 一次，結(jié)束的時候 CoUninitialize 一次。

我：我這里是較底層功能函數(shù)。

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

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

其實我被動搖了。

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

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

好，既然 CoInitialize 和 CoUninitialize 有引用計數(shù)機制，那么這個具體問題已經(jīng)解決。

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

如題。

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

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

那么，勢必要：

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

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

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

}

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

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

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

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

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

如果放寬要求，不要求在構(gòu)造函數(shù)提供內(nèi)存分配，那倒是有一種解法——分兩階段構(gòu)造：

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;
    }
};

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

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