伊人色综合久久,久久综合亚洲色HEZYO国产,7777精品伊人久久久大香线蕉

2011年8月11日

對C++ Local的經典分析

文章地址：  http://kittsoft.xp3.biz/?p=86

“這個問題比你想象中復雜”
（我也學下BS的風格，雖然這句話是我自己臨時想說的。^^）
從字符到整數
char是一種整數類型，這句話的含義是，char所能表示的字符在C/C++中都是整數類型。好，接下來，很多文章就會舉出一個典型例子，比如，’a' 的數值就是0×61。這種說法對嗎？如果你細心的讀過K&R和BS對于C和C++描述的原著，你就會馬上反駁道，0×61只是’a'的ASCII 值，并沒有任何規定C/C++的char值必須對應ASCII。C/C++甚至沒有規定char占幾位，只是規定了sizeof(char)等于1。
當然，目前大部分情況下，char是8位的，并且，在ASCII范圍內的值，與ASCII對應。
本地化策略集（locale）
“將’a'翻譯成0×61的整數值”，“將ASCII范圍內的編碼與char的整數值對應起來”，類似這樣的規定，是特定系統和特定編譯器制定的，C/C++中有個特定的名詞來描述這種規定的集合：本地化策略集（locale。也有翻譯成“現場”）。而翻譯——也就是代碼轉換（codecvt）只是這個集合中的一個，C++中定義為策略（facet。也有翻譯為“刻面”）
C/C++的編譯策略
“本地化策略集”是個很好的概念，可惜在字符和字符串這個層面上，C/C++并不使用（C++的locale通常只是影響流（stream）），C/C++使用更直接簡單的策略：硬編碼。
簡單的說，字符（串）在程序文件（可執行文件，非源文件）中的表示，與在程序執行中在內存中的表示一致。考慮兩種情況：
A、char c = 0×61;
B、char c = ‘a’;
情況A下，編譯器可以直接認識作為整數的c，但是在情況B下，編譯器必須將’a'翻譯成整數。編譯器的策略也很簡單，就是直接讀取字符（串）在源文件中的編碼數值。比如：
const char* s = “中文abc”;
這段字符串在GB2312（Windows 936），也就是我們的windows默認中文系統源文件中的編碼為：
0xD6   0xD0   0xCE 0xC4 0×61 0×62 0×63
在UTF-8，也就是Linux默認系統源文件中的編碼為：
0xE4   0xB8   0xAD   0xE6   0×96   0×87   0×61   0×62   0×63
一般情況下，編譯器會忠實于源文件的編碼為s賦值，例外的情況比如VC會自作聰明的把大部分其他類型編碼的字符串轉換成GB2312（除了像UTF-8 without signature這樣的幸存者）。
程序在執行的時候，s也就保持是這樣的編碼，不會再做其他的轉換。
寬字符 wchar_t
正如char沒有規定大小，wchar_t同樣沒有標準限定，標準只是要求一個wchar_t可以表示任何系統所能認識的字符，在win32 中，wchar_t為16位；Linux中是32位。wchar_t同樣沒有規定編碼，因為Unicode的概念我們后面才解釋，所以這里只是提一下，在 win32中，wchar_t的編碼是UCS-2BE；而Linux中是UTF-32BE（等價于UCS-4BE），不過簡單的說，在16位以內，一個字符的這3種編碼值是一樣的。因此：
const wchar_t* ws = L”中文abc”;
的編碼分別為：
0x4E2D   0×6587    0×0061   0×0062   0×0063                                                //win32，16位
0x00004E2D   0×00006587    0×00000061   0×00000062   0×00000063        //Linux，32位
大寫的L是告訴編譯器：這是寬字符串。所以，這時候是需要編譯器根據locale來進行翻譯的。
比如，在Windows環境中，編譯器的翻譯策略是GB2312到UCS-2BE；Linux環境中的策略是UTF-8到UTF-32BE。
這時候就要求源文件的編碼與編譯器的本地化策略集中代碼翻譯的策略一致，例如VC只能讀取GB2312的源代碼（這里還是例外，VC太自作聰明了，會將很多其他代碼在編譯時自動轉換成GB2312），而gcc只能讀取UTF-8的源代碼（這里就有個尷尬，MinGW運行win32下，所以只有 GB2312系統才認；而MinGW卻用gcc編寫，所以自己只認UTF-8，所以結果就是，MinGW的寬字符被廢掉了）。
寬字符（串）由編譯器翻譯，還是被硬編碼進程序文件中。

Unicode和UCS
Unicode和UCS是兩個獨立的組織分別制定的一套編碼標準，但是因為歷史的原因，這兩套標準是完全一樣的。Unicode這個詞用得比較多的原因可能是因為比較容易記住，如果沒有特別的聲明，在本文所提及的Unicode和UCS就是一個意思。Unicode的目標是建立一套可以包含人類所有語言文字符號你想得到想不到的各種東西的編碼，其編碼容量甚至預留了火星語以及銀河系以外語言的空間——開個玩笑，反正簡單的說，Unicode編碼集足夠的大，如果用計算機單位來表示，其數量比3個字節大一些，不到4個字節。
Unicode和UTF
因為Unicode包含的內容太多，其編碼在計算機中的表示方法就成為了一個有必要研究的問題。傳統編碼，比如標準的7位ASCII，在計算機中的表示方法就是占一個字節的后7位，這似乎是不需要解釋就符合大家習慣的表示方法。但是當今Unicode的總數達到32位（計算機的最小單位是字節，所以大于3 字節，就只能至少用4字節表示），對于大部分常用字符，比如Unicode編碼只占一個字節大小的英語字母，占兩個字節大小漢字，都用4個字節來儲存太奢侈了。另外，如果都用4字節直接表示，就不可避免的出現為0的字節。而我們知道，在C語言中，0×00的字節就是’\0′，表示的是一個字符串（char 字符串，非wchar_t）的結束，換句話說，C風格的char字符串無法表示Unicode。
因為類似的種種問題，為Unicode在計算機中的編碼方法出現了，這就是UTF；所對應的，為UCS編碼實現的方式也有自己的說法。一般來說，UTF- x，x表示這套編碼一個單位至少占用x位，因為Unicode最長達到32位，所以UTF-x通常是變長的——除了UTF-32；而UCS-y表示一個單位就占用y個字節，所以能表示當今Unicode的UCS-y只有UCS-4，但是因為歷史的原因，當Unicode還沒那么龐大的時候，2個字節足夠表示，所以有UCS-2，現在看來，UCS-2所能表示的Unicode只是當今Unicode的一個子集。
也就是說，如果某種編碼，能根據一定的規則算法，得到Unicode編碼，那么這種編碼方式就可以稱之為UTF。
UTF-8和Windows GB2312
UTF-8是一套“聰明”的編碼，可能用1，2，3，4個字節表示。通過UTF-8的算法，每一個字節表示的信息都很明確：這是不是某個Unicode編碼的第一個字節；如果是第一個字節，這是一個幾位Unicode編碼。這種“聰明”被稱為UTF-8的自我同步，也是UTF-8成為網絡傳輸標準編碼的原因。
另外，UTF-8也不會出現0字節，所以可以表示為char字符串，所以可以成為系統的編碼。Linux系統默認使用UTF-8編碼。
Windows GB2312一般自稱為GB2312，其實真正的名字應該是Windows Codepage 936，這也是一種變長的編碼：1個字節表示傳統的ASCII部分；漢字部分是兩個字節的GBK（國標擴（展），拼音聲母）。Codepage 936也可以表示為char字符串，是中文Windows系統的默認編碼。
我們在第1節中看到的
const char* s = “中文abc”;
在Windows中的編碼就是Codepage 936；在Linux中的編碼就是UTF-8。
需要注意的是，Codepage 936不像UTF，跟Unicode沒有換算的關系，所以只能通過“代碼頁”技術查表對應。
UTF-16和UCS-2
UTF-16用2個字節或者4個字節表示。在2個字節大小的時候，跟UCS-2是一樣的。UTF-16不像UTF-8，沒有自我同步機制，所以，編碼大位在前還是小位在前，就成了見仁見智的問題。我們在第1節中，“中”的UCS-2BE（因為是兩個字節，所以也就是UTF-16BE）編碼是0x4E2D，這里的BE就是大位在后的意思（也就是小位在前了），對應的，如果是UCS-2LE，編碼就成了0x2D4E。
Windows中的wchar_t就是采用UCS-2BE編碼。需要指出的是，C++標準中對wchar_t的要求是要能表示所有系統能識別的字符。Windows自稱支持Unicode，但是其wchar_t卻不能表示所有的Unicode，由此違背了C++標準。
UTF-32和UCS-4
UTF-32在目前階段等價于UCS-4，都用定長的4個字節表示。UTF-32同樣存在BE和LE的問題。Linux的wchar_t編碼就是UTF- 32BE。在16位以內的時候，UTF-32BE的后兩位（前兩位是0×00 0×00）等價于UTF-16BE也就等價于UCS-2BE
BOM
為了說明一個文件采用的是什么編碼，在文件最開始的部分，可以有BOM，比如0xFE 0xFF表示UTF-16BE，0xFF 0xFE 0×00 0×00表示UTF-32LE。UTF-8原本是不需要BOM的，因為其自我同步的特性，但是為了明確說明這是UTF-8（而不是讓文本編輯器去猜），也可以加上UTF-8的BOM：0xEF 0xBB 0xBF
以上內容都講述得很概略，詳細信息請查閱維基百科相關內容。

std::locale
通過前面兩節的知識，我們知道了在C/C++中，字符（串）和寬字符（串）之間的轉換不是簡單的，固定的數學關系，寬窄轉換依賴于本地化策略集（locale）。換句話說，一個程序在運行之前并不知道系統的本地化策略集是什么，程序只有在運行之后才通過locale獲得當時的本地化策略集。
C有自己的locale函數，我們這里直接介紹C++的locale類。
先討論locale的構造函數：
locale() throw();
這個構造函數是獲得當前程序的locale，用法如下：
std::locale app_loc = std::locale();
或者（這是構造對象的兩種表示方式，后同）
std::locale app_loc;
另外一個構造函數是：
explicit locale(const char* name);
這個構造函數以name的名字創建新的locale。重要的locale對象有：
std::locale sys_loc(“”);      //獲得當前系統環境的locale
std::locale C_loc(“C”);      或者      std::locale C_loc = std::locale::classic();      //獲得C定義locale
std::locale old_loc = std::locale::global(new_loc);      //將new_loc設置為當前全局locale，并將原來的locale返回給old_loc
除了這些，其它的name具體名字依賴于C++編譯器和操作系統，比如Linux下gcc中文系統的locale名字為”zh_CN.UTF-8″，中文Windows可以用”chs”（更加完整的名字可以用name()函數查看）。
mbstowcs()和wcstombs()
這兩個C運行時庫函數依賴于全局locale進行轉換，所以，使用前必須先設置全局locale。
std::locale已經包含在<iostream>中了，再加上我們需要用到的C++字符串，所以包含<string>。
我們先看窄到寬的轉換函數：

 const std::wstring s2ws(const std::string& s)   
 {   
     std::locale old_loc = std::locale::global(std::locale(""));   
     const char* src_str = s.c_str();   
     const size_t buffer_size = s.size() + 1;   
     wchar_t* dst_wstr = new wchar_t[buffer_size];   
     wmemset(dst_wstr, 0, buffer_size);   
     mbstowcs(dst_wstr, src_str, buffer_size);   
     std::wstring result = dst_wstr;   
     delete []dst_wstr;   
     std::locale::global(old_loc);   
     return result;   
 }

我們將全局locale設置為系統locale，并保存原來的全局locale在old_loc中。
在制定轉換空間緩存大小的時候，考慮如下：char是用1個或多個對象，也就是1個或者多個字節來表示各種符號：比如，GB2312用1個字節表示數字和字母，2個字節表示漢字；UTF-8用一個字節表示數字和字母，3個字節表示漢字，4個字節表示一些很少用到的符號，比如音樂中G大調符號等。 wchar_t是用1個對象（2字節或者4字節）來表示各種符號。因此，表示同樣的字符串，寬字符串的大小（也就是wchar_t對象的數量）總是小于或者等于窄字符串大小（char對象數量）的。+1是為了在最后預留一個值為0的對象，以便讓C風格的char或者wchar_t字符串自動截斷——這當然是寬串大小等于窄串大小的時候才會用上的，大部分時候，字符串早在前面某個轉換完畢的位置就被0值對象所截斷了。
最后我們將全局locale設置回原來的old_loc。
窄串到寬串的轉換函數：

 const std::string ws2s(const std::wstring& ws)   
 {   
     std::locale old_loc = std::locale::global(std::locale(""));   
     const wchar_t* src_wstr = ws.c_str();   
     size_t buffer_size = ws.size() * 4 + 1;   
     char* dst_str = new char[buffer_size];   
     memset(dst_str, 0, buffer_size);   
     wcstombs(dst_str ,src_wstr, buffer_size);   
     std::string result = dst_str;   
     delete []dst_str;   
     std::locale::global(old_loc);   
     return result;   
 }

這里考慮轉換空間緩存大小的策略正好相反，在最極端的情況下，所有的wchar_t都需要4個char來表示，所以最大的可能就是4倍加1。
這兩個函數在VC和gcc中都能正常運行（MinGW因為前面說到的原因不支持寬字符的正常使用），在VC中會給出不安全的警告，這是告訴給那些弄不清寬窄轉換實質的人的警告，對于了解到目前這些知識的你我來說，這就是啰嗦了。

locale和facet
C++的locale框架比C更完備。C++除了一個籠統本地策略集locale，還可以為locale指定具體的策略facet，甚至可以用自己定義的 facet去改造一個現有的locale產生一個新的locale。如果有一個facet類NewFacet需要添加到某個old_loc中形成新 new_loc，需要另外一個構造函數，通常的做法是：
std::locale new_loc(old_loc, new NewFacet);
標準庫里的標準facet都具有自己特有的功能，訪問一個locale對象中特定的facet需要使用模板函數use_facet：
template <class Facet> const Facet& use_factet(const locale&);
換一種說法，use_facet把一個facet類實例化成了對象，由此就可以使用這個facet對象的成員函數。
codecvt
codecvt就是一個標準facet。在C++的設計框架里，這是一個通用的代碼轉換模板——也就是說，并不是僅僅為寬窄轉換制定的。
templat <class I, class E, class State> class std::codecvt: public locale, public codecvt_base{…};
I表示內部編碼，E表示外部編碼，State是不同轉換方式的標識，如果定義如下類型：
typedef std::codecvt<wchar_t, char, mbstate_t> CodecvtFacet;
那么CodecvtFacet就是一個標準的寬窄轉換facet，其中mbstate_t是標準寬窄轉換的State。
內部編碼和外部編碼
我們考慮第1節中提到的C++編譯器讀取源文件時候的情形，當讀到L”中文abc”的時候，外部編碼，也就是源文件的編碼，是GB2312或者UTF-8 的char，而編譯器必須將其翻譯為UCS-2BE或者UTF-32BE的wchar_t，這也就是程序的內部編碼。如果不是寬字符串，內外編碼都是 char，也就不需要轉換了。類似的，當C++讀寫文件的時候，就會可能需要到內外編碼轉換。事實上，codecvt就正是被文件流緩存basic_filebuf所使用的。理解這一點很重要，原因會在下一小節看到。
CodecvtFacet的in()和out()
因為在CodecvtFacet中，內部編碼設置為wchar_t，外部編碼設置為char，轉換模式是標準寬窄轉換mbstate_t，所以，類方法 in()就是從char標準轉換到wchar_t，out()就是從wchar_t標準轉換到char。這就成了我們正需要的內外轉換函數。
result in(State& s, const E* from, const E* from_end, const E*& from_next, I* to, I* to_end, I*& to_next) const;
result out(State& s, const I* from, const I* from_end, const I*& from_next, E* to, E* to_end, E*& to_next) const;
其中，s是非const引用，保存著轉換位移狀態信息。這里需要重點強調的是，因為轉換的實際工作交給了運行時庫，也就是說，轉換可能不是在程序的主進程中完成的，而轉換工作依賴于查詢s的值，因此，如果s在轉換結束前析構，就可能拋出運行時異常。所以，最安全的辦法是，將s設置為全局變量！
const的3個指針分別是待轉換字符串的起點，終點，和出現錯誤時候的停點（的下一個位置）；另外3個指針是轉換目標字符串的起點，終點以及出現錯誤時候的停點（的下一個位置）。
代碼如下：
頭文件：

 //Filename string_wstring_cppcvt.hpp   
 #ifndef STRING_WSTRING_CPPCVT_HPP   
 #define STRING_WSTRING_CPPCVT_HPP   
 #include <iostream>   
 #include <string>   
 const std::wstring s2ws(const std::string& s);   
 const std::string ws2s(const std::wstring& s);   
 #endif

實現：

 #include "string_wstring_cppcvt.hpp"   
 mbstate_t in_cvt_state;   
 mbstate_t out_cvt_state;   
 const std::wstring s2ws(const std::string& s)   
 {   
     std::locale sys_loc("");   
     const char* src_str = s.c_str();   
     const size_t BUFFER_SIZE = s.size() + 1;   
     wchar_t* intern_buffer = new wchar_t[BUFFER_SIZE];   
     wmemset(intern_buffer, 0, BUFFER_SIZE);   
     const char* extern_from = src_str;   
     const char* extern_from_end = extern_from + s.size();   
     const char* extern_from_next = 0;   
     wchar_t* intern_to = intern_buffer;   
     wchar_t* intern_to_end = intern_to + BUFFER_SIZE;   
     wchar_t* intern_to_next = 0;   
     typedef std::codecvt<wchar_t, char, mbstate_t> CodecvtFacet;   
     CodecvtFacet::result cvt_rst =   
     std::use_facet<CodecvtFacet>(sys_loc).in(   
             in_cvt_state,   
             extern_from, extern_from_end, extern_from_next,   
             intern_to, intern_to_end, intern_to_next);   
     if (cvt_rst != CodecvtFacet::ok) {   
         switch(cvt_rst) {   
         case CodecvtFacet::partial:   
                 std::cerr << "partial";   
                 break;   
         case CodecvtFacet::error:   
                 std::cerr << "error";   
                 break;   
         case CodecvtFacet::noconv:   
                 std::cerr << "noconv";   
                 break;   
         default:   
                 std::cerr << "unknown";   
         }   
         std::cerr  << ", please check in_cvt_state."   
 << std::endl;   
     }   
     std::wstring result = intern_buffer;   
     delete []intern_buffer;   
     return result;   
 }   
 const std::string ws2s(const std::wstring& ws)   
 {   
     std::locale sys_loc("");   
     const wchar_t* src_wstr = ws.c_str();   
     const size_t MAX_UNICODE_BYTES = 4;   
     const size_t BUFFER_SIZE =   
                 ws.size() * MAX_UNICODE_BYTES + 1;   
     char* extern_buffer = new char[BUFFER_SIZE];   
     memset(extern_buffer, 0, BUFFER_SIZE);   
     const wchar_t* intern_from = src_wstr;   
     const wchar_t* intern_from_end = intern_from + ws.size();   
     const wchar_t* intern_from_next = 0;   
     char* extern_to = extern_buffer;   
     char* extern_to_end = extern_to + BUFFER_SIZE;   
     char* extern_to_next = 0;   
     typedef std::codecvt&lt;wchar_t, char, mbstate_t> CodecvtFacet;   
     CodecvtFacet::result cvt_rst =   
     std::use_facet<CodecvtFacet>(sys_loc).out(   
             out_cvt_state,   
             intern_from, intern_from_end, intern_from_next,   
             extern_to, extern_to_end, extern_to_next);   
     if (cvt_rst != CodecvtFacet::ok) {   
         switch(cvt_rst) {   
         case CodecvtFacet::partial:   
                 std::cerr << "partial";   
                 break;   
         case CodecvtFacet::error:   
                 std::cerr << "error";   
                 break;   
         case CodecvtFacet::noconv:   
                 std::cerr << "noconv";   
                 break;   
         default:   
                 std::cerr << "unknown";   
         }   
         std::cerr << ", please check out_cvt_state."   
 << std::endl;   
     }   
     std::string result = extern_buffer;   
     delete []extern_buffer;   
     return result;   
 }

最后補充說明一下std::use_facet<CodecvtFacet>(sys_loc).in()和 std::use_facet<CodecvtFacet>(sys_loc).out()。sys_loc是系統的locale，這個 locale中就包含著特定的codecvt facet，我們已經typedef為了CodecvtFacet。用use_facet對CodecvtFacet進行了實例化，所以可以使用這個 facet的方法in()和out()。

C++的流和本地化策略集
BS在設計C++流的時候希望其具備智能化，并且是可擴展的智能化，也就是說，C++的流可以“讀懂”一些內容。比如：

std::cout << 123 << “ok” << std::endl;

這句代碼中，std::cout是能判斷出123是int而”ok”是const char[3]。利用流的智能，甚至可以做一些基礎類型的轉換，比如從int到string，string到int：

 std::string str("123");   
 std::stringstream sstr(str);   
 int i;   
 sstr >&gt; i;  
  
 int i = 123;   
 std::stringstream sstr;   
 sstr <&lt; i;   
 std::string str = sstr.str();

盡管如此，C++并不滿足，C++甚至希望流能“明白”時間，貨幣的表示法。而時間和貨幣的表示方法在世界范圍內是不同的，所以，每一個流都有自己的locale在影響其行為，C++中叫做激活（imbue，也有翻譯成浸染）。而我們知道，每一個locale都有多個facet，這些facet并非總是被use_facet使用的。決定使用哪些facet的，是流的緩存basic_streambuf及其派生類basic_stringbuf和 basic_filebuf。我們要用到的facet是codecvt，這個facet只被basic_filebuf使用——這就是為什么只能用 fstream來實現寬窄轉換，而無法使用sstream來實現的原因。
頭文件：

 //filename string_wstring_fstream.hpp   
 #ifndef STRING_WSTRING_FSTREAM_HPP   
 #define STRING_WSTRING_FSTREAM_HPP   
 #include &lt;string>   
 const std::wstring s2ws(const std::string& s);   
 const std::string ws2s(const std::wstring& s);   
 #endif

實現：

 #include <string>   
 #include <fstream>   
 #include "string_wstring_fstream.hpp"   
 const std::wstring s2ws(const std::string& s)   
 {   
     std::locale sys_loc("");   
     std::ofstream ofs("cvt_buf");   
     ofs <&lt; s;   
     ofs.close();   
     std::wifstream wifs("cvt_buf");   
     wifs.imbue(sys_loc);   
     std::wstring wstr;   
     wifs >&gt; wstr;   
     wifs.close();   
     return wstr;   
 }   
 const std::string ws2s(const std::wstring& s)   
 {   
     std::locale sys_loc("");   
     std::wofstream wofs("cvt_buf");   
     wofs.imbue(sys_loc);   
     wofs <&lt; s;   
     wofs.close();   
     std::ifstream ifs("cvt_buf");   
     std::string str;   
     ifs >&gt; str;   
     ifs.close();   
     return str;   
 }

在窄到寬的轉化中，我們先使用默認的本地化策略集（locale）將s通過窄文件流ofs傳入文件，這是char到char的傳遞，沒有任何轉換；然后我們打開寬文件流wifs，并用系統的本地化策略集（locale）去激活（imbue）之，流在讀回寬串wstr的時候，就是char到 wchar_t的轉換，并且因為激活了sys_loc，所以實現標準窄到寬的轉換。
在寬到窄的轉化中，我們先打開的是寬文件流wofs，并且用系統的本地化策略集sys_loc激活（imbue）之，這時候，因為要寫的文件 cvt_buf是一個外部編碼，所以執行了從wchar_t到char的標準轉換。讀回來的文件流從char到char，不做任何轉換。

硬編碼的硬傷
我們現在知道，C/C++的寬窄轉換是依賴系統的locale的，并且在運行時完成。考慮這樣一種情況，我們在簡體中文Windows下編譯如下語句：
const char* s = “中文abc”;
根據我們之前的討論，編譯器將按照Windows Codepage936（GB2312）對這個字符串進行編碼。如果我們在程序中運行寬窄轉換函數，將s轉換為寬字符串ws，如果這個程序運行在簡體中文環境下是沒問題的，將執行從GB2312到UCS-2BE的轉換；但是，如果在其他語言環境下，比如是繁體中文BIG5，程序將根據系統的locale執行從BIG5到UCS-2BE的轉換，這顯然就出現了錯誤。
補救
有沒有補救這個問題的辦法呢？一個解決方案就是執行不依賴locale的寬窄轉換。實際上，這就已經不是寬窄轉換之間的問題了，而是編碼之間轉換的問題了。我們可以用GNU的libiconv實現任意編碼間的轉換，對于以上的具體情況，指明是從GB2312到UCS-2BE就不會出錯。（請參考本人前面的章節：win32下的libiconv），但這顯然是一個笨拙的策略：我們在簡體中文Windows下必須使用GB2312到UCS-2BE版本的寬窄轉換函數；到了BIG5環境下，就必須重新寫從BIG5到UCS-2BE的寬窄轉換函數。
Windows的策略
Windows的策略是淘汰了窄字符串，干脆只用寬字符串。所有的硬編碼全部加上特定宏，比如TEXT()，如果程序是所謂Unicode編譯，在編譯時就翻譯為UCS2-BE——Windows自稱為Unicode編程，其本質是使用了UCS-2BE的16位寬字符串。
Linux的策略
Linux下根本就不存在這個問題！因為各種語言的Linux都使用UTF-8的編碼，所以，無論系統locale如何變化，窄到寬轉換的規則一直是UTF-8到UTF32-BE 。
跨平臺策略
因為在16位的范圍內，UTF32-BE的前16位為0，后16位與UCS2-BE是一樣的，所以，即使wchar_t的sizeof()不一樣，在一般情況下，跨平臺使用寬字符（串）也應該是兼容的。但是依然存在潛在的問題，就是那些4字節的UTF32編碼。
gettext策略
以上都是將ASCII及以外的編碼硬編碼在程序中的辦法。GNU的gettext提供了另外一種選擇：在程序中只硬編碼ASCII，多語言支持由gettext函數庫在運行時加載。（對gettext的介紹請參考本人前面的章節：Win32下的GetText）。 gettext的多語言翻譯文件不在程序中，而是單獨的提出來放在特定的位置。gettext明確的知道這些翻譯文件的編碼，所以可以準確的告訴給系統翻譯的正確信息，而系統將這些信息以當前的系統locale編碼成窄字符串反饋給程序。例如，在簡體中文Windows中，gettext的po文件也可以以UTF-8儲存，gettext將po文件翻譯成mo文件，確保mo文件在任何系統和語言環境下都能夠正確翻譯。在運行是傳給win32程序的窄串符合當前locale，是GB2312。gettext讓國際化的翻譯更加的方便，缺點是目前我沒找到支持寬字符串的版本（據說是有ugettext()支持寬字符串），所以要使用gettext只能使用窄字符串。但是gettext可以轉換到寬字符串，而且不會出現寬窄轉換的問題，因為gettext是運行時根據locale翻譯的。例如：
const char* s = gettext(“Chinese a b c”);
其中”Chinese a b c”在po中的翻譯是”中文abc”
使用依賴locale的運行時寬窄轉換函數：
const std::wstring wstr = s2ws(s);
運行時調用該po文件對應的mo文件，在簡體中文環境下就以GB2312傳給程序，在繁體中文中就以BIG5傳給程序，這樣s2ws()總能夠正常換算編碼。
更多
在本文的最后，我想回到C++的stream問題上。用fstream轉換如此的簡單，sstream卻不支持。改造一個支持codecvt的 string stream需要改造basic_stringbuf。basic_stringbuf和basic_filebuf都派生自 basic_streambuf，所不同的是basic_filebuf在構造和open()的時候調用了codecvt，只需要在 basic_stringbuf中添加這個功能就可以了。說起來容易，實際上是需要重新改造一個STL模板，盡管這些模板源代碼都是在標準庫頭文件中現成的，但是我還是水平有限，沒有去深究了。另外一個思路是構建一個基于內存映射的虛擬文件，這個框架在boost的iostreams庫中，有興趣的朋友可以深入的研究。
（完）

posted @ 2011-08-11 00:08 李陽閱讀(6679) | 評論 (2) | 編輯收藏

2010年2月25日

關于C++中的臨時對象問題

摘要: C++中真正的臨時對象是看不見的，它們不出現在你的源代碼中，臨時對象的產生在如下幾個時刻: 1. 用構造函數作為隱式類型轉換函數時，會創建臨時對象。例： class Integer &nb... 閱讀全文

posted @ 2010-02-25 14:44 李陽閱讀(4764) | 評論 (6) | 編輯收藏

2010年1月7日

剖析Windows消息處理機制

前一段，幫人寫了個小控件，又溫習了一遍Windows消息處理機制，現在把一些知識點總結出來，供大家參考.

1.窗口
Windows程序是由一系列的窗口構成的，每個窗口都有自己的窗口過程，窗口過程就是一個擁有有固定 Signature 的 C函數，具體格式如下：

   LRESULT CALLBACK WindowProc(HWND hwnd,
       UINT uMsg,
       WPARAM wParam,
       LPARAM lParam
   );

   窗口類型：
   可重疊窗口(Overlapped Window)，
   彈出窗口(Pop-up Window)，
   子窗口(Child Window)

   窗口之間的關系: 父子關系，擁有關系，前后關系。

2.線程
    一個進程至少擁有一個線程，稱為主線程，如果一個線程創建了窗口，擁有GUI資源，那么也稱該線程為GUI線程,否則就為工作線程。窗口是由線程創建的，
創建窗口的線程就擁有該窗口。這種線程擁有關系的概念對窗口有重要的意義：建立窗口的線程必須是為窗口處理所有消息的線程。為了使這個概念更加明
確具體，可以想像一個線程建立了一個窗口，然后就結束了。在這種情況下，窗口不會收到一個WM_DESTROY或WM_NCDESTROY消息，因為線程已經結束，不可
能被用來使窗口接收和處理這些消息。每個線程，如果它至少建立了一個窗口，都由系統對它分配一個消息隊列。這個隊列用于窗口消息的派送(dispatch)。
為了使窗口接收這些消息，線程必須有它自己的消息循環，消息循環一般如下：

MSG msg;
while( GetMessage(&msg, NULL, 0, 0) )
{
  TranslateMessage (&msg);
  DispatchMessage (&msg);
}

應用程序不斷的從消息隊列中獲取消息,然后系統通過DispatchMessage函數分派消息到相應窗口的窗口過程，使得消息得到處理。當獲取到WM_QUIT消息時，
GetMessage返回0，循環結束。

3.消息
消息，就是指Windows發出的一個通知，告訴應用程序某個事情發生了。例如，單擊鼠標、改變窗口尺寸、按下鍵盤上的一個鍵都會使Windows發送一個消息
給應用程序，它被定義為：
  typedef struct {
  HWND hwnd;    //窗口句柄, 發生在哪個窗口上
  UINT message;   //消息標識號 ( WM_MOUSEMOVE, WM_LBUTTONDOWN, ... )
  WPARAM wParam;   //消息參數1
  LPARAM lParam;   //消息參數2
  DWORD time;
  POINT pt;
} MSG, *PMSG;
一個消息結構體包含了該事件所有完備信息，當應用程序收到該消息時，就可以做出相應處理了。

消息分類

<1>.隊列消息和非隊列消息

從消息的發送途徑上看，消息分兩種：隊列消息和非隊列消息。
隊列消息送到系統消息隊列，然后到線程消息隊列；非隊列消息直接送給目的窗口過程。

  這里，對消息隊列闡述如下：
  Windows維護一個系統消息隊列(System message queue)，每個GUI線程有一個線程消息隊列(Thread message queue)。鼠標、鍵盤事件由鼠標或鍵盤驅動
  程序轉換成輸入消息并把消息放進系統消息隊列，例如WM_MOUSEMOVE、WM_LBUTTONUP、WM_KEYDOWN、WM_CHAR等等。Windows每次從系統消息隊列移走一個
  消息，確定它是送給哪個窗口的和這個窗口是由哪個線程創建的，然后，把它放進窗口創建線程的線程消息隊列。線程消息隊列接收送給該線程所創建窗口
  的消息。線程從消息隊列取出消息，通過Windows把它送給適當的窗口過程來處理。

  除了鍵盤、鼠標消息以外，隊列消息還有WM_PAINT、WM_TIMER和WM_QUIT。這些隊列消息以外的絕大多數消息是非隊列消息。

<2>.系統消息和應用程序消息

從消息的來源來看，可以分為：系統定義的消息和應用程序定義的消息。

  系統消息ID的范圍是從0到WM_USER-1，或0X80000到0XBFFFF；應用程序消息從WM_USER(0X0400)到0X7FFF，或0XC000到0XFFFF；WM_USER到0X7FFF范圍的消息
  由應用程序自己使用；0XC000到0XFFFF范圍的消息用來和其他應用程序通信，為了ID的唯一性，使用::RegisterWindowMessage來得到該范圍的消息ID。

<3>.窗口消息，命令消息，控件通知消息
  根據處理過程的不同,可以分為三類：窗口消息，命令消息，控件通知消息。

  (1).窗口消息
   一般以WM_開頭，如WM_CREATE, WM_SIZE, WM_MOUSEMOVE等標準的Windows消息, 用于窗口相關的事件通知，窗口消息將由系統分配到該窗口的窗口過程處理。
  (2).命令消息 (WM_COMMAND)
   一種特殊的窗口消息，它從一個窗口發送到另一個窗口以處理來自用戶的請求，通常是從子窗口發送到父窗口，例如，點擊按鈕時，按鈕的父窗口會收到
   WM_COMMAND消息，用以通知父窗口按鈕被點擊，經測試：子窗口向父窗口發送WM_COMMAND消息，或者稱為父窗口會收到WM_COMMAND消息，操作系統并不是
   通過將WM_COMMAND消息放入到父窗口的消息隊列中去，而是直接調用了父窗口的窗口過程，以 WM_COMMAND 為消息標識參數(UINT uMsg)，實現這個功能的
   API函數正是: LRESULT DispatchMessage(const MSG *lpmsg);
  (3).控件通知消息
   WM_NOTIFY消息，當用戶與控件交互(Edit, Button...)時，通知消息會從控件窗口發送到父窗口，這種消息的目的不是為了處理用戶命令，而是為了讓父窗
   口能夠適時的改變控件。

4.測試
<1>.測試代碼:

消息循環中，將從消息隊列中取出的消息逐一打印出來，

while(GetMessage(&msg, NULL, 0, 0))

{

char buf[1024];

sprintf_s(buf, 1024, "hWnd:%d uMsg: %d WParam: %d LParam: %d\n",

msg.hwnd, msg.message, msg.wParam, msg.lParam);

std::cout<<buf;

TranslateMessage(&msg);

DispatchMessage(&msg);

}

在窗口過程中，如果收到 WM_COMMAND 消息，就在窗口上輸入來。

LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)

{

switch (message)

{

case WM_COMMAND:

HDhdc = GetDC (hwnd) ;

SelectObject (hdc, GetStockObject (SYSTEM_FIXED_FONT)) ;

TextOut(hdc, 24 * cxChar, cyChar * (rect.bottom / cyChar - 1),

szBuffer,

wsprintf(szBuffer, szFormat,

TEXT ("WM_COMMAND"),

HIWORD(wParam), LOWORD(wParam),

HIWORD(lParam), LOWORD(lParam))

);

ReleaseDC (hwnd, hdc) ;

ValidateRect (hwnd, &rect) ;

break ;

}

return DefWindowProc (hwnd, message, wParam, lParam) ;

}

      <2>.運行結果
    一個窗口，窗口上有一個按鈕子窗口，然后還有一個控制臺，輸出消息循環中的每條消息，當父窗口收到 WM_COMMAND 消息時，
    會在屏幕上輸出。

(1). 當鼠標在父窗口上移動時：

可見父窗口 hWnd: 461982，uMsg : 521 ( WM_MOUSEMOVE )，從線程消息隊列中取出的。

(2). 當鼠標在按鈕子窗口上移動時：

可見按鈕 hWnd: 462118，uMsg : 521 ( WM_MOUSEMOVE)，從線程消息隊列中取出的。

(3). 當鼠標在父窗口上點擊時：

父窗口收到了 513(WM_LBUTTONDOWN), 514(WM_LBUTTONUP) 消息，從線程消息隊列中取出的。

(4). 當鼠標在按鈕窗口上點擊時：

         按鈕窗口從線程的消息隊列中取出了 513(WM_LBUTTONDOWN), 514(WM_LBUTTONUP) 消息，父窗口收到了WM_COMMAND
         消息，TextOut 繪制出 WM_COMMAND 文本。


         我在 WM_COMMAND 的消息處理語句處打有斷點，看下圖:

         可見，窗口過程是被系統調用的，調用時系統傳入的參數值為：
                        hwnd:          0x00070c9e，十進制就是461982，父窗口句柄；
                        message:      273 (WM_COMMAND)
                        wParam:      ...
                         lParam:       ...
          具體是WinMain中的哪一個函數中最后調用了窗口過程 WndProc 呢，見下圖：

            原來是在 DispatchMessage 函數中，再看看參數的值：
            msg.hwnd:             0x00070d26，十進制是462118，是按鈕窗口的句柄;
            msg.message:         514 ( WM_LBUTTONUP )
            哦~~~~，原來是操作系統在從該線程的消息隊列中取出按鈕的 WM_LBUTTONUP (鼠標左鍵釋放) 消息后，調用
            DispatchMessage 分派消息，DispatchMessage 會先將 WM_LBUTTONUP 消息分派到按鈕的窗口過程(系統默認有)，
            這里的分派到按鈕的窗口過程就是調用俺就的窗口過程，然后又以按鈕的父窗口的句柄為窗口過程的第一個
            參數， WM_COMMAND 為窗口過程的第二個參數調用了父窗口的窗口過程，也就是將 WM_COMMAND
            消息分發到了父窗口，從而使父窗口得到了通知。這些，都是 Windows 來完成的，應用程序只需要在相應的窗口
            過程中處理相應的消息。

            從上面，我們還可以看出，WM_COMMAND 是非隊列消息，直接分派到目的窗口過程，而不是放入到消息隊列中，
            讓消息循環去取。

總結:

           簡而言之，標準Windows消息發送到產生窗口，通知消息(WM_COMMAND, WM_NOTIFY)發送到父窗口，這是Windows
           的標準消息處理過程，MFC對 Window API 進行了封裝，有自己的一套消息處理流程，消息順著一條路徑流動，需要
           處理的對象可以添加消息響應函數處理之，對于命令消息，它有 CView , CDocument, CMainFram , CWinApp 一系列處理
          節點，對于通知消息，MFC還加入一種很好的機制：消息反射，就是父窗口收到子窗口發出的通知消息后，會將此消息
           發送給子窗口，先讓子窗口處理，如果子窗口不處理，父窗口再處理之，這樣有利于將所有消息處理代碼都集成了子窗口
           中，有利于控件的開發。MFC的消息處理，我不予詳細討論了，有興趣的可以參考侯捷的<<深入淺出MFC>>。

posted @ 2010-01-07 16:17 李陽閱讀(11802) | 評論 (2) | 編輯收藏

2009年7月8日

關于 return void()

大家都知道，return 用來在函數里返回，有兩種形式：一是直接用return; 或者省略，表示無返回值。二是 return expression; 返回一個值。
今天測試時我發現兩種以前沒注意的方式，也是正確的。

<1>.

void FuncA()

{

return void(); //正確的，同：return;

}

<2>.

void FuncB()

{

return FuncA();//也可以，同： FuncA();

}

這兩種特性在某些情況下，是很有用的。比如，我要寫一個函數模板，以任意的模板參數類型 T 為返回值。

template <typename T>

T FuncC()

{

return T(); //這里舉例返回 T();

}

template <typename T>

T FuncD()

{

return FuncC<T>();

}

所以即使對于返回值為 void 的情況，FuncD<void>(); 也是適用的。
如果編譯器不支持這種特性。那么當我們就得針對void返回類型進行特化，或者函數重載，示例代碼如下：

//一般處理

template <typename T>

T FuncE()

{

return FuncC<T>();

}

//特化版本

template<>

void FuncE<void>()

{

FuncC<void>();

}

//或者進行重載亦可

void FuncE()

{

FuncC<void>();

}

void Test()

{

FuncE<int>(); //泛化版本

FuncE<void>(); //特化版本

FuncE(); //重載版本

}

FuncE函數沒有參數，可以特化或者重載，但如果它還有其他模板參數的話，由于函數模板不支持部分特化，就只能使用重載模板函數了。

發現這種方式后，為我省了很多事，原來為了識別一個模板參數是否為void，我模擬stl 搞了個 templeate <typename T> Return_Type_Trait {}，然后利用類模板的特化來專門定義一些類型，以到達識別返回類型的目的。現在看來，都是多余的。可以使用這個特性來實現。

posted @ 2009-07-08 11:54 李陽閱讀(9553) | 評論 (0) | 編輯收藏

對C++ Local的經典分析

常用鏈接

留言簿(7)

隨筆分類

隨筆檔案

文章分類

文章檔案

鏈接

友情鏈接

搜索

最新評論

閱讀排行榜

評論排行榜

對C++ Local的經典分析

Related Posts:

常用鏈接

留言簿(7)

隨筆分類

隨筆檔案

文章分類

文章檔案

鏈接

友情鏈接

搜索

最新評論

閱讀排行榜

評論排行榜