可冰

將語法作以下修改就好了。

rule<> group, factor, term, expression, integer;

group = * space_p >> '(' >> expression >> * space_p >> ')' >> * space_p;
integer = * space_p >> int_p[Push()] >> * space_p;
factor = integer | group;
term = factor
>> *( (* space_p >> '*' >> factor) [&mul2]
| (* space_p >> '/' >> factor) [&div2] )
;
expression = term
>> *( (* space_p >> '+' >> term) [&add2]
| (* space_p >> '-' >> term) [&sub2] )
;

不錯(cuò)。
不知道naven了解ACE不，感覺有一點(diǎn)類似。不過我覺得更像JAVA。

可以完全用OpenGL來做GUI嗎，比如文本輸入框、對話框等等，比起MFC來哪個(gè)好用一些。我最近要做GUI程序，但又不想學(xué)MFC，不知道該用什么好。

任務(wù)體系結(jié)構(gòu)
在任務(wù)體系結(jié)構(gòu)領(lǐng)域里，有三種主要的技術(shù)：
* 單進(jìn)程單任務(wù)（面向進(jìn)程）：在同一時(shí)間里，程序的每一份拷貝都作為一個(gè)任務(wù)來處理。有時(shí)，建立一個(gè)新的進(jìn)程，同時(shí)也就建立了一個(gè)新的任務(wù)（比如： inetd、Sendmail）或者進(jìn)程可以被重用（如：Apache）。在低負(fù)載的時(shí)候，這種體系結(jié)構(gòu)一般可以獲得較好的性能。在中等負(fù)載時(shí)，如果進(jìn)程映像比較小（如：qmail）、應(yīng)用程序經(jīng)過執(zhí)行效率的優(yōu)化或者應(yīng)用程序不會(huì)創(chuàng)建太多的并發(fā)任務(wù)，那么還可以勉強(qiáng)應(yīng)付。在這種情況下，如果總的進(jìn)程數(shù)保持較低的數(shù)量（低于中等負(fù)載），并且使用了進(jìn)程緩沖，那么對多處理器系統(tǒng)的利用率將比較高。這種技術(shù)存在于所有的操作系統(tǒng)中，不過實(shí)現(xiàn)起來Unix比 Windows效率要高得多。（Windows中沒有fork()系統(tǒng)調(diào)用，并且由于這種方法太慢，所以很少有Windows應(yīng)用程序采用這種技術(shù)。）
* 單線程單任務(wù)（多線程）：在完成任務(wù)的過程中，程序的每一個(gè)拷貝在進(jìn)程內(nèi)部都作為了一個(gè)獨(dú)立的線程來執(zhí)行。在低負(fù)載到中等負(fù)載的情況下，多進(jìn)程應(yīng)用程序的性能都非常的好。對于比較高的負(fù)載，性能將會(huì)下降，但是還可以接受。然而，當(dāng)負(fù)載非常高的時(shí)候，多線程應(yīng)用程序的性能會(huì)急劇下降。在一般情況下，典型的多線程應(yīng)用程序在處理500到1000個(gè)任務(wù)并發(fā)任務(wù)時(shí)，其性能還可以容忍。每一個(gè)任務(wù)使用一個(gè)新的線程，這樣和一個(gè)新的進(jìn)程比起來，將消耗較少的內(nèi)存和 CPU資源。因?yàn)樵跇O重的多線程負(fù)載下，只有那些目前使用非常廣泛的 UNIX變種才能夠繼續(xù)保持穩(wěn)定，所以在源代碼開放的項(xiàng)目中，很少使用多線程。
* 單線程多任務(wù)（異步方式）：一個(gè)程序使用一系列的線程來運(yùn)行（一般來說，每一個(gè)特定的任務(wù)都有專門的線程來處理），并且使用所謂的異步（或者叫無阻塞） TCP/IP技術(shù)，每一個(gè)線程要處理很多的任務(wù)。一般來說，由于大部分程序并不要求去處理高負(fù)載的情況，并且異步模式的程序設(shè)計(jì)相對來說比較困難，所以很少會(huì)有程序采用這種體系結(jié)構(gòu)。因?yàn)榭梢允褂酶髯元?dú)立的線程，所以多處理器系統(tǒng)中，異步程序的可伸縮性要好得多。因?yàn)閹缀醪粫?huì)因等待CPU而死鎖，所以每一個(gè)線程基本上都可以長時(shí)間地分配到一個(gè)CPU（比如：DNS BIND監(jiān)控程序）。
[引用自chinaunix：http://bbs.chinaunix.net/viewthread.php?tid=56099]

謝謝大家的支持,我會(huì)繼續(xù)下去的。

@Stone Jiang
謝謝你的建議。我覺得“不要拘泥于小節(jié)”比較好，我馬上就改過來。

純虛的析構(gòu)函數(shù)可以用來定義抽象類，這樣就避免了實(shí)例化（正如作者所說的），而且另外一個(gè)好處是可以不用再在抽象類中定義另一個(gè)純虛函數(shù)（這種情況很常見）來避免實(shí)例化。因?yàn)槌橄箢惪偸菦]有析構(gòu)函數(shù)的，或者說抽象類的析構(gòu)函數(shù)是無用的、多余的，現(xiàn)在正好變廢為寶。

但是這里的純虛析構(gòu)函數(shù)是可以不用實(shí)現(xiàn)的，否則還如何來避免實(shí)例化，也更不成其為純虛函數(shù)了啊。

Jamie Zawinski的網(wǎng)站真是牛啊!佩服至極!

系統(tǒng)手冊[2-15]
--------------------------------------
RESET
When the nRESET signal goes LOW, ARM920T abandons the executing instruction and then continues to fetch
instructions from incrementing word addresses.
When nRESET goes HIGH again, ARM920T:
1. Overwrites R14_svc and SPSR_svc by copying the current values of the PC and CPSR into them. The value of
the saved PC and SPSR is not defined.
2. Forces M[4:0] to 10011 (Supervisor mode), sets the I and F bits in the CPSR, and clears the CPSR's T bit.
3. Forces the PC to fetch the next instruction from address 0x00.
4. Execution resumes in ARM state.
--------------------------------------
當(dāng)~nRESET信號(低電平有效)有效時(shí),ARM920T終止當(dāng)前指令的執(zhí)行,而連續(xù)不斷地獲取下一字地址處的指令;當(dāng)~nRESET恢復(fù)為高電平時(shí),ARM920T執(zhí)行下面的操作:
1. 拷貝當(dāng)前PC和CPSR的值到R14_svc和SPSR_svc中.而保存過的PC和SPSR的值未定義(不確定).
2. M[4:0] <-- 10011,轉(zhuǎn)到Supervisor模式,設(shè)置CPSR中的I、F位為1(禁止中斷),并對T位清零(進(jìn)入ARM狀態(tài)).
3. 設(shè)置PC從0x00處獲取下一條指令.
4. 在ARM狀態(tài)下執(zhí)行指令.

還有一種代碼密度更高的寫法：
（但不推薦使用，可讀性太差了！）
while( *s && *s++ &= 0xDF )
　　　　；
其實(shí)對于指針的話還應(yīng)該加上一條判斷：
while( s && *s && *s++ &= 0xDF )
　　　　；

/**************************************/
// 利用字符串?dāng)?shù)組的結(jié)尾都是 \0
void ToUpper(chars[])
{
　　　　int i=0;
　　　　while(s[i++]!='\0' )
　　　　{　　＾＾＾＾＾
/**************************************/
你這個(gè)i自加的可不是時(shí)候啊

另外，其實(shí)只要一條語句就可實(shí)現(xiàn)轉(zhuǎn)換的.
while( s[i] != '\0' )
　　s[i++] &= 0xDF; // 11011111B
/*或者*/
while( *s != '\0' )
　　*s++ &= 0xDF;

看來還是知識不過硬啊!

是嗎?
我沒有在其它編譯器下測試,只是看了它的錯(cuò)誤說明,我還以為真是這樣的呢.
我完了再試一下吧.
謝謝了!

看題好像沒有計(jì)算重復(fù)點(diǎn)吧,如果計(jì)算的話上面的圖中的交點(diǎn)數(shù)可能就不夠22個(gè)了.
如果要計(jì)算的話,我想可以用方程來表示線,計(jì)算出每個(gè)交點(diǎn)的坐標(biāo)來.

其實(shí)原理很簡單,只要知道棧是如何運(yùn)作的就可以.
棧其實(shí)就相當(dāng)于一個(gè)數(shù)組,函數(shù)的參數(shù)都被儲存到這個(gè)數(shù)組中.C方式的參數(shù)傳遞是從后向前的,由于棧頂是大的地址,入棧時(shí)棧頂指針減小,所以以這種方式存儲參數(shù)的話,最后參數(shù)在內(nèi)存中的映象就是想于從前到后的一個(gè)數(shù)組了.
所以,只要知道第一個(gè)元素(即這里的參數(shù))的地址及后面的元素個(gè)數(shù)和類型,就可以一個(gè)一個(gè)的把參數(shù)取出來.在使用變長參數(shù)時(shí)一定至少要有一個(gè)固定參數(shù)就是這個(gè)道理.
知道這樣的原理的話就可以在程序在通過第一個(gè)參數(shù)的地址來取得后面的元素了.比如這樣一個(gè)函數(shù):
void foo( int n, ... );
其中n表示后面的參數(shù)的個(gè)數(shù).而我在使用時(shí)隱式約定后面的參數(shù)都是整型的,即int,就可以這樣獲得后面的參數(shù)了:
void* p = &n + 1; //指向后面的第一個(gè)參數(shù)
while( n-- ) {
int* num = (int*)p;
//use *num
p = (int*)p + 1; //通過類型轉(zhuǎn)換才可以知道1是多少字節(jié).
}
這樣就可以不用stdarg.h而使用變長參數(shù)了.
其實(shí)stdarg.h里面沒有什么內(nèi)容,只是定義了幾個(gè)宏,有幾個(gè)還是空的宏.
但最好還是用它里面定義的宏,而且在普通函數(shù)中也是完全有理由用它的,并不是只有庫函數(shù)才可以.

注意是Reserved Byte Stored
在內(nèi)存中是 68 61 70 70 79

happy

這樣的代碼的結(jié)果是不確定的，并沒有規(guī)定；就是在不同的編譯器下有不同的結(jié)果是完全合乎標(biāo)準(zhǔn)的。
況且搞這些玩意沒有任何用處，不如多寫寫代碼呢。

請問boost庫里有沒有XML的解析器,以及對Socket的封裝？

這是照書翻譯的，呵呵。
我英語不太好，語文也不太好，所以可能會(huì)有點(diǎn)亂吧。
大家有興趣的話一起來幫忙修改一下嘛^-^

count[index^1] = 0; // count[index?0:1] = 0; // count[index==0?1:0] = 0;
//===========================
覺得不如下面這個(gè)可讀性好或簡潔：
count[ ! index ] = 0;

個(gè)人意見哈^-^

覺得樓主劃分不錯(cuò)。一開始不要分得太細(xì)，可以將一樓說的一些參與不太多的類別歸到一個(gè)子類下面，若有很多人參與，再提上來不遲。
而且我看樓主主要是從技術(shù)角度上分的，而一樓朋友是從應(yīng)用角度上分的，兩者怎么樣折中一下可能比較好吧。

go here for hints:
　　　　http://www.rickadams.org/adventure/d_hints/index.html

我雖然沒有勇氣和能力來做這樣的事情,但我在學(xué)校也是可以做一些改變的.不再用學(xué)校的一套來衡量自己的水平,而要看實(shí)際的能力,只去努力提升自己的能力.

----------------------------------------
看到王垠的另一篇文章,也一起貼到這邊來吧.

<<完全用Linux工作，擯棄Windows>>
http://news.csdn.net/news/newstopic/26/26606.shtml

那你們是怎么過的?可以獨(dú)立了嗎?
我在學(xué)校一個(gè)感覺就是幾乎所有東西都是我自學(xué)的,而上課時(shí)又必須去,于是去了就睡覺或玩或偶爾也看書.我還沒有勇氣做這樣的事情,因?yàn)槲业哪芰€不夠,我沒有多少經(jīng)濟(jì)支撐,家里還等著我畢業(yè)工作幫一點(diǎn)忙呢.
我很羨慕你們,能有這樣的勇氣.因此,我想你們以后的路也不難走吧.

[摘錄]Boost源碼剖析之:泛型函數(shù)指針類boost::function(修訂版)
劉未鵬 /文

或許你會(huì)對模板參數(shù)int(int)感到陌生，其實(shí)它是個(gè)函數(shù)型別——函數(shù)g的確切型別就是int(int)，而我們通常所看到的函數(shù)指針型別int (*)(int)則是&g的型別。它們的區(qū)別與聯(lián)系在于：當(dāng)把g作為一個(gè)值進(jìn)行拷貝的時(shí)候（例如，按值傳參），其類型就會(huì)由int(int)退化為int(*)(int)，即從函數(shù)類型退化為函數(shù)指針類型——因?yàn)閺恼Z義上說，函數(shù)不能被“按值拷貝”，但身為函數(shù)指針的地址值則是可以被拷貝的。另一方面，如果g被綁定到引用，則其類型不會(huì)退化，仍保持函數(shù)類型。
......
請注意，函數(shù)類型乃是個(gè)極其特殊的類型，在大多數(shù)時(shí)候它都會(huì)退化為函數(shù)指針類型，以便滿足拷貝語義，只有面對引用綁定的時(shí)候，能夠維持原來的類型。當(dāng)然，對于boost::function，總是按值拷貝。

謝謝你的批評.我也正是認(rèn)識到這個(gè)問題后來向大家尋求幫助的.
另外你給我建議很不錯(cuò)的,可以考慮那樣的實(shí)現(xiàn).

嗯,確實(shí)是.
你說的是對的,模板不能濫用,"模板一般用在批量產(chǎn)生代碼、加強(qiáng)類型檢查、提高效率、普通代碼不好解決問題的時(shí)候".以后我會(huì)記住的.
其實(shí),我確實(shí)可能是有一點(diǎn)追求復(fù)雜代碼的傾向,寫代碼時(shí)考慮代碼最多,而不是具體的運(yùn)用.在這一點(diǎn)上我是走錯(cuò)路了.
以后一定要改!

我在模板中試了一下,確實(shí)用函數(shù)類型定義的變量成為了函數(shù)指針類型.
定義為: T var;
輸出為: var: void (__thiscall Base<void __cdecl(int)>::*)(int)
T : void __cdecl(int)

但是在外部,定義這樣的一個(gè)類型及變量:
typedef void MethodType (int);
MethodType method;

它們的類型居然是一樣的,method在這兒并沒有轉(zhuǎn)化為函數(shù)指針類型.
輸出類型如下:
void __cdecl(int)
void __cdecl(int)

這又是怎么回事?

謝謝提醒.我已經(jīng)將文件轉(zhuǎn)放在博客園上,現(xiàn)在可以下載了.

void(int)原來是函數(shù)類型啊!從來沒有見到過這樣的類型啊.
你所說的"當(dāng)把void(int)類型的函數(shù)作為一個(gè)值來傳遞時(shí)，它自動(dòng)退化為void(*)(int)指針類型。"應(yīng)該是指,用它來定義變量的時(shí)候,這個(gè)變量就成了函數(shù)指針類型的了?

這個(gè)肯定有用了啊!
還可以,和我以前想的一樣,但我還不太了解DLL的用法,所以也就沒有實(shí)現(xiàn).而且我總感覺這樣做不是很好,但又想不到更好的.現(xiàn)在我就省點(diǎn)力借借光吧,用的時(shí)候完善一下就直接用了.
不過,我不知道在LINUX及其它系統(tǒng)上面是不是也有DLL機(jī)制的方式來實(shí)現(xiàn)同樣的功能.

哦,我以前問過這樣的問題,不知道看到的是不是我問的.
不管了,反正好好學(xué)習(xí)就是了.

如何下載你的代碼呢?cnblogs上看不到啊

看了這個(gè)又稍微理解多一些了,關(guān)注中...

不知道我的看法是否正確,還請賜教.

看了你這樣子使用模板,真是服了!
我原來不明白你所說的"讓編譯器根據(jù)in/out來推導(dǎo)出函數(shù)原型",現(xiàn)在可能明白了:
你是用嵌套的模板,以后使用遞歸方式,來讓編譯器在編譯時(shí)刻生成合適的類.其中最主要的還是If模板類吧,是它可以讓編譯器遞歸的分析的.還有In/Out/InOut及其對應(yīng)的TypeTraits模板類,這樣的用法是我從來都沒有想到過的.

我從來沒有想過這樣的用法.
而且,你的模板使用的太好了,很靈活.這個(gè)代碼我欣賞著很舒服,很喜歡.

也許你進(jìn)行泛型編程有一段時(shí)間了吧,我只是有一點(diǎn)的了解,也沒有學(xué)過和用過.你的代碼我只看得懂,看得舒服,感覺很精妙,但其中的精髓我沒法理解,我是萬萬寫不出這樣的代碼來的.

前篇中所說的那幾本書我都沒有讀過呢,以后有機(jī)會(huì)一定認(rèn)真讀.
你的這一系列文章我一直在關(guān)注中,希望你能堅(jiān)持下去.我還等著研讀你的大作呢

C++的程序員真的不好找工作嗎?

想去啊，多么想去啊。可就是去不了啊。希望去過的朋友帶點(diǎn)資料回來就很高興了。

如果我有能力參與的話,我一定會(huì)參加的.
我對分布式以及Web Service也是很感興趣,只是沒有相關(guān)的知識和經(jīng)驗(yàn).
雖然如此,但至少我也會(huì)大力支持的!

9: int main()
10: {
0041F540 push ebp
0041F541 mov ebp,esp
0041F543 push 0FFFFFFFFh
0041F545 push offset __ehhandler$_main (45638Bh)
0041F54A mov eax,dword ptr fs:[00000000h]
0041F550 push eax
0041F551 mov dword ptr fs:[0],esp
0041F558 sub esp,17Ch
0041F55E push ebx
0041F55F push esi
0041F560 push edi
0041F561 lea edi,[ebp-188h]
0041F567 mov ecx,5Fh
0041F56C mov eax,0CCCCCCCCh
0041F571 rep stos dword ptr [edi]
　　　　　11: //wifstream wf( "utf8.txt" );
　　　　　12: std::wifstream wf;
0041F573 push 1
0041F575 lea ecx,[wf]
0041F57B call std::basic_ifstream<unsigned short,std::char_traits<unsigned short> >::basic_ifstream<unsigned short,std::char_traits<unsigned short> > (41D285h)
0041F580 mov dword ptr [ebp-4],0

是啊,這里有對esp,edi,ebp等的操作,但我不明白這是什么意思;-( 我還沒學(xué)32位下的匯編呢.

不懂BOM是什么意思?
在UTF-8中它們沒出現(xiàn)過,應(yīng)該是正確的吧.

我覺得你這種從調(diào)用習(xí)慣入手進(jìn)行分析的方式挺不錯(cuò)的,這樣用起來會(huì)很自然,很方便,而且也容易把握全局.若是從原理方面入手進(jìn)行代碼編寫的話,很可能會(huì)使最后開發(fā)出的代碼很難用,也不容易把握好全局的關(guān)系.
我一直想實(shí)現(xiàn)一個(gè)XML的解析器,總是寫了一些代碼后覺得不合理就再重來,這樣會(huì)反復(fù)好幾次.直到現(xiàn)在,還在那放著沒有做.我想用你這樣的分析方式再嘗試一次,看看會(huì)怎么樣.

哦,我查了一下,局部變量是在棧上的.
是我記錯(cuò)了,動(dòng)態(tài)分配的空間才是從堆上分配.

很不錯(cuò).看了第一篇時(shí)根本看不懂是干什么呢,但這一篇就看得懂了.以這樣的方式實(shí)現(xiàn)遠(yuǎn)程調(diào)用確實(shí)是很簡單.
順便問一下作者,你正在實(shí)現(xiàn)這一內(nèi)容嗎?

@ffox:
這樣是將對變量的讀寫操作封裝起來以接口的形式提供,它在提供了一定的接口一致性.如果以后要在讀寫變量的操作內(nèi)加入其它的操作,那么原有的代碼就可以不加任何修改,只改這樣的接口就行了.也就是對外部封閉了細(xì)節(jié),使編程簡單一點(diǎn).
但我也覺得不能用"一刀切"的方式將所有的成員變量都加以這樣的封裝,這樣無疑會(huì)使代碼增長(而且可能還有我所不知道的缺點(diǎn)).
所以,可以作如下的總結(jié):
對于要對外部提供應(yīng)用的變量,最好以接口的形式提供;而如果只是內(nèi)部用的話,在用途只是用于保存變量的值的話,直接聲明為public會(huì)好一些.
具體的情況還要加以區(qū)別對待,根據(jù)實(shí)際情況加以應(yīng)用.

@cpunion
從C＋＋語言的發(fā)展方向上，很難看到他們有在語言層面上跨平臺的打算。
--------------
確實(shí),但我覺得現(xiàn)在語言層面動(dòng)態(tài)的需求是很大的,尤其是做應(yīng)用開發(fā)的.而C++卻是在已經(jīng)做得不錯(cuò)的效率上下工夫,而且現(xiàn)在又要加入一些保證安全的語言特征.這可不符合大勢所趨啊.所以我覺得C++也會(huì)往這方面發(fā)展的吧.
其實(shí)我覺得那些C++的元老對C++的發(fā)展起了太大的作用,而他們又是比較保守的,所以導(dǎo)致C++發(fā)展緩慢.我覺得現(xiàn)在JAVA的方式不錯(cuò),通過JCP社區(qū)最終決定它的發(fā)展方向.
也許也是我錯(cuò)了吧:也許C++并不想走"大眾化"的道路,或是那些元老不想讓它走.
但我認(rèn)為使用者才是擁有最終決定權(quán)的.

@FrameSniper
"現(xiàn)在？你的意思是以前不是了？"
----------
當(dāng)然不是了,我的文字不好,沒有講明白,謝謝你指正.

另外,我不認(rèn)為跨平臺只有依靠虛擬機(jī).像cpunion所說,只要系統(tǒng)提供一致的接口就行.但是,如果接口差異不是很大,我想應(yīng)該可以靠編譯器的工作來轉(zhuǎn)換.
我的意思也不是要讓生成的可執(zhí)行文件實(shí)現(xiàn)跨平臺,而是在一個(gè)中間代碼的層次實(shí)現(xiàn),而后由編譯器針對各系統(tǒng)的不同而生成不同的程序.雖然這也不是完全的跨平臺,但在開發(fā)者的角度看也差不多了,而且可以通過編譯器的實(shí)現(xiàn)來將中間代碼的編譯速度提高,這樣也可以實(shí)現(xiàn).NET所謂的即時(shí)編譯,即第一次運(yùn)行的時(shí)候編譯,以后就不用編譯了.其實(shí)在虛擬機(jī)上,也不是可以生成目標(biāo)操作系統(tǒng)的機(jī)器代碼嗎,但它的效率應(yīng)該不及C/C++了吧.

確實(shí),在現(xiàn)在的應(yīng)用中動(dòng)態(tài)性是很重要的,而且也通常會(huì)使開發(fā)出來的產(chǎn)品有很高的可擴(kuò)展性.C++對這個(gè)的支持確實(shí)很少.不過我想如果結(jié)合編譯器的一些功能與特性,這樣的動(dòng)態(tài)性還是可以實(shí)現(xiàn)的,而且還有可能實(shí)現(xiàn)中間代碼級的跨平臺性.

其實(shí)他這個(gè)方式不一定有效,因?yàn)镃++的類成員的內(nèi)存布局可以與聲明的順序不一樣,而不象C的結(jié)構(gòu)中的成員一樣,要完全的一致.所以他這樣的實(shí)現(xiàn)有賴于編譯器的實(shí)現(xiàn),而不能得到語言級的保證.

到現(xiàn)在我天天都在用它收發(fā)很多信的,可還是沒有發(fā)邀請的權(quán)限啊.
仍然郁悶的等待中.....