久久久久亚洲av成人网人人软件,久久久久国产视频电影,日产精品久久久久久久

關(guān)于模板的類型參數(shù)

看了cpunion寫的IDL的代碼,我知道了這樣的用法:
在模板參數(shù)中,類型參數(shù)可以這樣構(gòu)造:
??????? template_class< type( type1, type2, ... ) > a_class;
比如,可以void( void ), void(), void( int ), 也可以int( void ), string( int )等等,編譯器是將它們當(dāng)作不同的類型的來處理的.對此,我寫了一些代碼作了一下測試(見文末).但我也僅僅是有一個(gè)感性的認(rèn)識而已,對于其為什么可以這樣(因?yàn)閺奈匆娔谋緯辖榻B過這樣的用法),我一點(diǎn)也不知道.
希望大家?guī)臀裔屢?也希望cpunion來幫我一下,謝謝!

#include?<iostream>

typedef?void(*fun)(int);

using?namespace?std;

template<?typename?T?>

struct?Base

{

????void?test()

????{

????????cout?<<?"Base"?<<?"\t=\t";

????????cout?<<?"Base<"?<<?typeid(T).name()?<<?">"?<<?endl;

????}

};

template<>

struct?Base?<?void?>

{

????void?test()

????{

????????cout?<<?"Base"?<<?endl;

????}

};

template<>

struct?Base?<?void(?int?)?>

{

????void?test()

????{

????????cout?<<?"Base"?<<?endl;

????}

};

template<>

struct?Base?<?fun?>

{

????void?test()

????{

????????cout?<<?"Base"?<<?endl;

????}

};

template<>

struct?Base?<?int(?string,?int,?char?)?>

{

????void?test()

????{

????????cout?<<?"Base"?<<?endl;

????}

};

int?main(int?argc,?char*?argv[])

{

????Base<?void?>?b_void;

????Base<?void(?int?)?>?b_void_int;

????b_void.test();

????b_void_int.test();

????Base<?int(?string,?int,?char?)?>?b_int;

????Base<?fun?>?b_fun;

????b_int.test();

????b_fun.test();

????Base<?Base<?void?>?(?Base?<?int?(?string,?int,?char?)?>?)?>?b_complex;

????b_complex.test();

????return?0;

}

posted @ 2005-09-29 19:51 可冰閱讀(2245) | 評論 (9) | 編輯收藏

<<神話>>片尾曲詞

隔世纏綿今世難續(xù)緣
心依然夢里的諾言未改變

人間凄然
不如一笑去了燭花散
塵花醉酒
輪回前塵成云煙

霓紅點(diǎn)點(diǎn) 凡間迷亂情淺
如當(dāng)年幻夢間牽手
心依然

因果皆緣
不如一醉罷了浮花散
情語醉人輪回前塵成誓言

劍如飛心如水
也隔不斷相思淚
歌不悔心還醉
究竟是為誰

愛若苦心無顧
誰拿愛情一生賭
翅斷了碟兒飛了
化作一世深緣故

[來源:http://msn.ynet.com/Events.jsp?eid=6367298]

posted @ 2005-09-25 10:26 可冰閱讀(369) | 評論 (0) | 編輯收藏

error C2899: 不能在模板聲明之外使用類型名稱 ?!!

前天碰到一個(gè)問題,當(dāng)時(shí)想著挺納悶的,不知道是什么原因.對"不能在模板聲明之外使用類型名稱"這樣的提示你會想到是什么?我在無意中按F1鍵看到MSDN中的描述才明白是typename關(guān)鍵字用錯(cuò)了,是看它的英文描述才知道的:"typename cannot be used outside a template declaration".真想不到typename會翻譯為類型名稱.看來,以后有莫名其妙的錯(cuò)誤還是得看英文的幫助文檔啊,不過最好一開始就有英文版的VS.NET.
以下是具體的描述:

namespace?code

{

enum?CodeType?{?UTF_8,?UNICODE?};

template<?CodeType?srcT,?CodeType?desT?>

struct?ConvertType{};

template<>

struct?ConvertType?<?UTF_8,?UNICODE?>

{

????typedef?char?srcType;

????typedef?wchar_t?desType;

};

template<?CodeType?srcT,?CodeType?desT?>

struct?Convert?{};

template<>

struct?Convert<?UTF_8,?UNICODE?>

{

????//error?C2899:?不能在模板聲明之外使用類型名稱

????typedef?typename?ConvertType<?UTF_8,?UNICODE?>::srcType?srcType;????//!

????typedef?typename?ConvertType<?UTF_8,?UNICODE?>::desType?desType;????//!

};

}?//namespace?code

這里根本不需要typename.

typename除用在模板聲明中外,只能用于說明模板類的成員是一個(gè)類型.

例如:

template?class?X?{};

//?Another?way

template?struct?X?{

????typedef?double?DoubleType;

????typename?X::DoubleType?a;???//?T::A?is?a?type

};

而如果不是模板類,則不能用typename.這時(shí),它并不是多余的,而是一定不能要的.

例如:

template<>?struct?X?>?{

????typename?X::DoubleType?a;????//Error!?X?is?not?a?generic?class

????X::DoubleType?b;????????//OK!

};

我前面的代碼也是這樣的情況,ConvertType已經(jīng)是一個(gè)具體的類了,不要是模板類,所以ConvertType::srcType前不能加typename.

posted @ 2005-09-24 15:49 可冰閱讀(8975) | 評論 (6) | 編輯收藏

構(gòu)思UTF-8解碼模塊

想實(shí)現(xiàn)一個(gè)解碼UTF-8格式文檔為Unicode格式代碼的"引擎",要用起來方便順手.
但想了幾天了,都沒有一個(gè)合適的方案來實(shí)現(xiàn).
唉......
今天先試著寫了寫,找找感覺,接著再想吧...

posted @ 2005-09-22 23:24 可冰閱讀(1056) | 評論 (1) | 編輯收藏

std::wfstream是怎么支持寬字符的?

std::wfstream的定義為:
typedef basic_fstream<wchar_t, char_traits<wchar_t> > wfstream;
在讀取字符時(shí):
wfstream wfile( "wcharfile.txt" );
wchar_t wch = wfile.get();
按語義講應(yīng)該是讀入兩個(gè)字節(jié)內(nèi)容的.但經(jīng)輸出檢測,它卻只讀入一個(gè)字節(jié),這樣和fstream還有什么分別?
到底在處理Unicode編碼的文件時(shí),應(yīng)該如何使用寬字符流?

posted @ 2005-09-22 22:47 可冰閱讀(2878) | 評論 (4) | 編輯收藏

"這是一個(gè)UTF-8格式的文檔!"的幾種不同編碼表示

posted @ 2005-09-20 20:39 可冰閱讀(489) | 評論 (1) | 編輯收藏

UTF-8 編碼格式總結(jié)

[以下只是個(gè)人的總結(jié),如若有誤,懇請指正,謝謝!]
下列字節(jié)串用來表示一個(gè)字符. 用到哪個(gè)串取決于該字符在 Unicode 中的序號.

U+00000000 - U+0000007F:	0 xxxxxxx	0x - 7x
U+00000080 - U+000007FF:	110 xxxxx 10 xxxxxx	Cx 8x - Dx Bx
U+00000800 - U+0000FFFF:	1110 xxxx 10 xxxxxx 10 xxxxxx	Ex 8x 8x - Ex Bx Bx
U+00010000 - U+001FFFFF:	11110 xxx 10 xxxxxx 10 xxxxxx 10 xxxxxx	F0 8x 8x 8x - F7 Bx Bx Bx	很少用
U+00200000 - U+03FFFFFF:	111110 xx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx	F8 8x 8x 8x 8x - FB Bx Bx Bx Bx
U+04000000 - U+7FFFFFFF:	1111110 x 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx	FC 8x 8x 8x 8x 8x - FD Bx Bx Bx Bx Bx

* FE FF從未在編碼中出現(xiàn)過.
* 除第一個(gè)字節(jié)外,其余字節(jié)都在 0x80 到 0xBF范圍內(nèi),每個(gè)字符的起始位置用0xC0-0xD0,0xE0,0xF0等可以確定(驗(yàn)證前四位或八位),不在這一范圍的即為單字節(jié)字符.凡是以0x80 到 0xBF開頭的都是后繼字節(jié),計(jì)數(shù)時(shí)都要跳過.
* Unicode是一種編碼表,只將字符指定給某一數(shù)字(Unicode做得還要更多一些,比如提供比較及顯示等很多算法等等);
而UTF-8是編碼方式,是定義如何表示并存儲指定編碼的格式.
* UTF-8編碼轉(zhuǎn)換為Unicode編碼: 將所有標(biāo)志位去除,剩余位數(shù)若不足則在高位補(bǔ)零,湊足32位即可.
* Unicode編碼轉(zhuǎn)換為UTF-8編碼: 從低位開始,每取6位補(bǔ)兩個(gè)位10,不足6位(不算高位的0)則按字節(jié)長度補(bǔ)相應(yīng)的字符標(biāo)志位0、110、1110等

posted @ 2005-09-19 20:03 可冰閱讀(10356) | 評論 (3) | 編輯收藏

UTF types

UTF	Estimated average storage required per page (3000 characters)
UTF-8	3 KB (1999) 5 KB (2003)	On average, English takes slightly over one unit per code point. Most Latin-script languages take about 1.1 bytes. Greek, Russian, Arabic and Hebrew take about 1.7 bytes, and most others (including Japanese, Chinese, Korean and Hindi) take about 3 bytes. Characters in surrogate space take 4 bytes, but as a proportion of all world text they will always be very rare.
UTF-16	6 KB	All of the most common characters in use for all modern writing systems are already represented with 2 bytes. Characters in surrogate space take 4 bytes, but as a proportion of all world text they will always be very rare.
UTF-32	12 KB	All take 4 bytes

[來源: http://icu.sourceforge.net/docs/papers/forms_of_unicode/]

UTF-8(ISO 10646-1) 有以下特性:

UCS 字符 U+0000 到 U+007F (ASCII) 被編碼為字節(jié) 0x00 到 0x7F (ASCII 兼容). 這意味著只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
所有 > U+007F 的 UCS 字符被編碼為一個(gè)或多個(gè)字節(jié)的串, 每個(gè)字節(jié)都有標(biāo)記位集. 因此, ASCII 字節(jié) (0x00-0x7F) 不可能作為任何其他字符的一部分.
表示非 ASCII 字符的多字節(jié)串的第一個(gè)字節(jié)總是在 0xC0 到 0xFD 的范圍里, 并指出這個(gè)字符包含多少個(gè)字節(jié). 多字節(jié)串的其余字節(jié)都在 0x80 到 0xBF 范圍里. 這使得重新同步非常容易, 并使編碼無國界, 且很少受丟失字節(jié)的影響.
可以編入所有可能的 2³¹個(gè) UCS 代碼
UTF-8 編碼字符理論上可以最多到 6 個(gè)字節(jié)長, 然而 16 位 BMP 字符最多只用到 3 字節(jié)長.
Bigendian UCS-4 字節(jié)串的排列順序是預(yù)定的.
字節(jié) 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.

下列字節(jié)串用來表示一個(gè)字符. 用到哪個(gè)串取決于該字符在 Unicode 中的序號.

U-00000000 - U-0000007F:	0xxxxxxx
U-00000080 - U-000007FF:	110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:	1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 的位置由字符編碼數(shù)的二進(jìn)制表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個(gè)足夠表達(dá)一個(gè)字符編碼數(shù)的多字節(jié)串. 注意在多字節(jié)串中, 第一個(gè)字節(jié)的開頭"1"的數(shù)目就是整個(gè)串中字節(jié)的數(shù)目.

例如: Unicode 字符 U+00A9 = 1010 1001 (版權(quán)符號) 在 UTF-8 里的編碼為:

11000010 10101001 = 0xC2 0xA9

而字符 U+2260 = 0010 0010 0110 0000 (不等于) 編碼為:

11100010 10001001 10100000 = 0xE2 0x89 0xA0

這種編碼的官方名字拼寫為 UTF-8, 其中 UTF 代表 UCS Transformation Format. 請勿在任何文檔中用其他名字 (比如 utf8 或 UTF_8) 來表示 UTF-8, 當(dāng)然除非你指的是一個(gè)變量名而不是這種編碼本身.

什么編程語言支持 Unicode?

在大約 1993 年之后開發(fā)的大多數(shù)現(xiàn)代編程語言都有一個(gè)特別的數(shù)據(jù)類型, 叫做 Unicode/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.

ISO C 也詳細(xì)說明了處理多字節(jié)編碼和寬字符 (wide characters) 的機(jī)制, 1994 年 9 月 Amendment 1 to ISO C 發(fā)表時(shí)又加入了更多. 這些機(jī)制主要是為各類東亞編碼而設(shè)計(jì)的, 它們比處理 UCS 所需的要健壯得多. UTF-8 是 ISO C 標(biāo)準(zhǔn)調(diào)用多字節(jié)字符串的編碼的一個(gè)例子, wchar_t 類型可以用來存放 Unicode 字符.
[來源: http://www.linuxforum.net/books/UTF-8-Unicode.html]

posted @ 2005-09-19 15:38 可冰閱讀(374) | 評論 (0) | 編輯收藏

UTF serializations

UTF-8	Inital `EF BB BF` is a signature, indicating that the rest of the file is UTF-8. Any `EF BF BE` is an error. A real ZWNBSP at the start of a file requires a signature first.
UTF-8N	All of the text is normal UTF-8; there is no signature. Inital `EF BB BF` is a ZWNBSP. Any `EF BF BE` is an error.
UTF-16	Initial `FE FF` is a signature indicating the rest of the text is big endian UTF-16. Initial `FF FE` is a signature indicating the rest of the text is little endian UTF-16. If neither of these are present, all of the text is big endian. A real ZWNBSP at the start of a file requires a signature first.
UTF-16BE	All of the text is big endian: there is no signature. Initial `FE FF` is a ZWNBSP. Any `FF FE` is an error.
UTF-16LE	All of the text is little endian: there is no signature. Initial `FF FE` is a ZWNBSP. Any `FE FF` is an error.
UTF-32	Initial `00 00 FE FF` is a signature indicating the rest of the text is big endian UTF-32. Initial `FF FE 00 00` is a signature indicating the rest of the text is little endian UTF-32. If neither of these are present, all of the text is big endian. A real ZWNBSP at the start of a file requires a signature first.
UTF-32BE	All of the text is big endian: there is no signature. Initial `00 00 FE FF` is a ZWNBSP. Any `FF FE 00 00` is an error.
UTF-32LE	All of the text is little endian: there is no signature. Initial `FF FE 00 00` is a ZWNBSP. Initial `00 00 FE FF` is an error.

Note: The italicized names are not yet registered, but are useful for reference.

[from: http://icu.sourceforge.net/docs/papers/forms_of_unicode/]

posted @ 2005-09-19 15:23 可冰閱讀(339) | 評論 (0) | 編輯收藏

學(xué)匯編想到的一些問題

在匯編中,用CALL調(diào)用子程序時(shí),處理器要保存當(dāng)前的狀態(tài).但具體地來說,它會保存哪些寄存器的值呢?
首先保存的應(yīng)該就是返回地址了吧,但這一過程可不可以用其它代碼來顯式的實(shí)現(xiàn)呢?也就是用push or mov等將它所做的工作代替,這樣可能嗎?

另外,C/C++中的局部變量是在哪里分配的呢?我記得好像是在堆上,但不太清楚了.這一過程在匯編中是如何實(shí)現(xiàn)的呢?看過了C的反匯編代碼還是沒搞清楚啊.

posted @ 2005-09-19 12:57 可冰閱讀(470) | 評論 (4) | 編輯收藏

僅列出標(biāo)題

可冰

公告

常用鏈接

留言簿(7)

隨筆分類(18)

隨筆檔案(37)

文章分類(5)

文章檔案(5)

相冊

朋友的博客

收藏

我的博客組

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜

什么編程語言支持 Unicode?