青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

可冰

冰,是沉睡著的水......

  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
  37 隨筆 :: 5 文章 :: 94 評論 :: 0 Trackbacks

#

看了cpunion寫的IDL的代碼,我知道了這樣的用法:
在模板參數(shù)中,類型參數(shù)可以這樣構(gòu)造:
??????? template_class< type( type1, type2, ... ) > a_class;
比如,可以void( void ), void(), void( int ), 也可以int( void ), string( int )等等,編譯器是將它們當(dāng)作不同的類型的來處理的.對此,我寫了一些代碼作了一下測試(見文末).但我也僅僅是有一個感性的認(rè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 可冰 閱讀(2271) | 評論 (9)編輯 收藏

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

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

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

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

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

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

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

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

前天碰到一個問題,當(dāng)時想著挺納悶的,不知道是什么原因.對"不能在模板聲明之外使用類型名稱"這樣的提示你會想到是什么?我在無意中按F1鍵看到MSDN中的描述才明白是typename關(guān)鍵字用錯了,是看它的英文描述才知道的:"typename cannot be used outside a template declaration".真想不到typename會翻譯為類型名稱.看來,以后有莫名其妙的錯誤還是得看英文的幫助文檔啊,不過最好一開始就有英文版的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除用在模板聲明中外,只能用于說明模板類的成員是一個類型.
例如:
template?class?X?{};

//?Another?way
template?struct?X?{
????typedef?double?DoubleType;

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

而如果不是模板類,則不能用typename.這時,它并不是多余的,而是一定不能要的.
例如:
template<>?struct?X?>?{
????typename?X::DoubleType?a;????//Error!?X?is?not?a?generic?class
????X::DoubleType?b;????????//OK!
};

我前面的代碼也是這樣的情況,ConvertType已經(jīng)是一個具體的類了,不要是模板類,所以ConvertType::srcType前不能加typename.
*/
posted @ 2005-09-24 15:49 可冰 閱讀(9068) | 評論 (6)編輯 收藏

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

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


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

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

[以下只是個人的總結(jié),如若有誤,懇請指正,謝謝!]
下列字節(jié)串用來表示一個字符. 用到哪個串取決于該字符在 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)過.
* 除第一個字節(jié)外,其余字節(jié)都在 0x80 到 0xBF范圍內(nèi),每個字符的起始位置用0xC0-0xD0,0xE0,0xF0等可以確定(驗證前四位或八位),不在這一范圍的即為單字節(jié)字符.凡是以0x80 到 0xBF開頭的都是后繼字節(jié),計數(shù)時都要跳過.
* Unicode是一種編碼表,只將字符指定給某一數(shù)字(Unicode做得還要更多一些,比如提供比較及顯示等很多算法等等);
而UTF-8是編碼方式,是定義如何表示并存儲指定編碼的格式.
* UTF-8編碼轉(zhuǎn)換為Unicode編碼: 將所有標(biāo)志位去除,剩余位數(shù)若不足則在高位補零,湊足32位即可.
* Unicode編碼轉(zhuǎn)換為UTF-8編碼: 從低位開始,每取6位補兩個位10,不足6位(不算高位的0)則按字節(jié)長度補相應(yīng)的字符標(biāo)志位0、110、1110等

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

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

下列字節(jié)串用來表示一個字符. 用到哪個串取決于該字符在 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ù)的二進制表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個足夠表達一個字符編碼數(shù)的多字節(jié)串. 注意在多字節(jié)串中, 第一個字節(jié)的開頭"1"的數(shù)目就是整個串中字節(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)然除非你指的是一個變量名而不是這種編碼本身.

什么編程語言支持 Unicode?

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

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

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


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 可冰 閱讀(355) | 評論 (0)編輯 收藏

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

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

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

僅列出標(biāo)題
共4頁: 1 2 3 4 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲激情影视| 欧美日韩网址| 一二三区精品福利视频| 亚洲春色另类小说| 久久亚裔精品欧美| 亚洲麻豆视频| 午夜亚洲伦理| 亚洲激情在线播放| 国产精品夜夜夜| 久久精视频免费在线久久完整在线看 | 久久精品色图| 欧美一区午夜视频在线观看| 久久国内精品视频| 亚洲天天影视| 久久久久久久久久久久久9999| 国产一区二区精品在线观看| 久久免费99精品久久久久久| 久久蜜臀精品av| 欧美日韩国产123区| 欧美在线视频免费观看| 久久久人成影片一区二区三区观看 | 亚洲一区999| 激情久久五月天| 国产精品v一区二区三区| 久久久精品国产免大香伊| 久久久噜噜噜久久中文字免| 欧美国产一区视频在线观看| 久久久999| 欧美巨乳波霸| 久久久最新网址| 欧美日韩精品一区二区天天拍小说 | 欧美日韩一区综合| 国产精品免费在线| 模特精品在线| 美日韩精品免费观看视频| 亚洲天堂av电影| 久久躁日日躁aaaaxxxx| 久久久久久国产精品一区| 欧美人交a欧美精品| 国产一区91| 中文无字幕一区二区三区| 一级日韩一区在线观看| 亚洲日本国产| 亚洲精品久久在线| 亚洲欧美日韩精品久久久久| 宅男精品视频| 亚洲综合第一页| 亚洲欧美日韩一区二区在线| 久久男人资源视频| 老司机精品视频网站| 久久久久久久尹人综合网亚洲| 欧美国产日韩一区二区三区| 久久影视三级福利片| 久久国产精品久久久久久久久久 | 亚洲视频专区在线| 欧美高清hd18日本| 亚洲国产激情| 亚洲图片你懂的| 久久影视三级福利片| 久热精品在线| 影音先锋日韩资源| 很黄很黄激情成人| 国产伦精品一区二区| 国产精品视频一区二区三区| 亚洲精品日韩一| 亚洲国产小视频在线观看| 亚洲第一黄网| 日韩系列在线| 亚洲欧美一区二区三区在线| 久久精品30| 欧美高清在线观看| 免费看亚洲片| 在线 亚洲欧美在线综合一区| 久久精品水蜜桃av综合天堂| 亚洲视频在线观看网站| 国产精品www994| 午夜一区二区三视频在线观看| 欧美在线三级| 狂野欧美激情性xxxx欧美| 亚洲午夜电影网| 尤物yw午夜国产精品视频| 禁断一区二区三区在线| 另类激情亚洲| 噜噜噜91成人网| 亚洲精品一区二区在线观看| 亚洲免费av电影| 亚洲激情视频在线播放| 欧美精品在线免费播放| 亚洲精品久久久久久久久久久 | 精品99一区二区| 久热精品视频在线观看| 老司机67194精品线观看| 亚洲国产欧美一区二区三区丁香婷| 欧美sm视频| 一本久道综合久久精品| 欧美三日本三级少妇三2023| 国产日韩欧美在线看| 久久最新视频| 欧美国产日韩免费| 亚洲免费中文| 久久一区欧美| 亚洲欧美日韩一区二区在线| 久久久久久亚洲精品杨幂换脸| 永久555www成人免费| 亚洲精品小视频| 黑人中文字幕一区二区三区| 一区二区三区久久久| 国产精品乱码一区二三区小蝌蚪| 久久精品日韩| 国产精品第13页| 99xxxx成人网| 亚洲第一黄网| 国产一区二区三区奇米久涩 | 亚洲第一综合天堂另类专| 99国产精品| 国产精品专区一| 国产一区二区三区的电影| 国产精品乱码一区二三区小蝌蚪| 亚洲午夜三级在线| 99re热精品| 亚洲国产精品v| 亚洲欧美国产精品桃花| 欧美另类一区| 国产亚洲精品bv在线观看| 亚洲欧洲在线观看| 欧美国产一区二区| 国产日本欧美一区二区三区在线| 欧美一区二区三区免费在线看| 欧美日韩国产一区精品一区| 欧美日韩另类丝袜其他| 久久久99国产精品免费| 欧美日韩精品久久久| 久久夜色精品国产欧美乱极品| 美女日韩欧美| 亚洲一区二区综合| 欧美护士18xxxxhd| 99在线观看免费视频精品观看| 国产精品99久久不卡二区| 亚洲国产裸拍裸体视频在线观看乱了| 日韩视频―中文字幕| 亚洲欧美日韩专区| 亚洲国产91| 最新亚洲电影| 亚洲精品乱码久久久久久蜜桃麻豆 | 久久天天综合| 久久天堂av综合合色| 国产一区二区三区免费不卡| 国产精品久久久久一区二区| 亚洲蜜桃精久久久久久久| 午夜精品一区二区三区在线播放| 亚洲国产精品va在线观看黑人| 亚洲欧美区自拍先锋| 亚洲电影网站| 亚洲在线视频免费观看| 欧美高清视频www夜色资源网| 亚洲国产精品专区久久| 一本色道精品久久一区二区三区| 久久久国际精品| 国产精品久久久久秋霞鲁丝 | 国产精品亚洲综合一区在线观看| 亚洲第一狼人社区| 女人香蕉久久**毛片精品| 久久精品女人的天堂av| 在线观看一区视频| 欧美成人有码| 国产精品久久久久久超碰| 亚洲自拍16p| 欧美在线视频免费播放| 亚洲国产成人av在线| 亚洲人成网站999久久久综合| 女女同性女同一区二区三区91| 亚洲国产成人久久综合一区| 亚洲第一精品久久忘忧草社区| 欧美激情国产精品| 亚洲国产精品久久久| 国产欧美一区二区精品忘忧草| 老司机免费视频久久| 国产精品乱子乱xxxx| 亚洲国产精品www| 国产精品在线看| 欧美xxx成人| 在线成人激情黄色| 99视频精品全国免费| 伊人久久大香线蕉av超碰演员| 日韩午夜精品视频| 宅男在线国产精品| 亚洲网站啪啪| 国产人成精品一区二区三| 亚洲视频在线观看网站| 久久成人亚洲| 午夜一区二区三视频在线观看| 久久久久久久久蜜桃| 久久精品在线播放| 国产精品porn| 99精品热视频| 午夜精品久久久久久久99热浪潮| 欧美日本高清一区| 亚洲精品孕妇| 亚洲三级性片| 午夜在线观看免费一区|