可冰

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

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] )
;

不錯。
不知道naven了解ACE不，感覺有一點類似。不過我覺得更像JAVA。

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

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

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

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

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

但是這里的純虛析構(gòu)函數(shù)是可以不用實現(xiàn)的，否則還如何來避免實例化，也更不成其為純虛函數(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.
--------------------------------------
當~nRESET信號(低電平有效)有效時,ARM920T終止當前指令的執(zhí)行,而連續(xù)不斷地獲取下一字地址處的指令;當~nRESET恢復(fù)為高電平時,ARM920T執(zhí)行下面的操作:
1. 拷貝當前PC和CPSR的值到R14_svc和SPSR_svc中.而保存過的PC和SPSR的值未定義(不確定).
2. M[4:0] <-- 10011,轉(zhuǎn)到Supervisor模式,設(shè)置CPSR中的I、F位為1(禁止中斷),并對T位清零(進入ARM狀態(tài)).
3. 設(shè)置PC從0x00處獲取下一條指令.
4. 在ARM狀態(tài)下執(zhí)行指令.

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

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

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

看來還是知識不過硬啊!

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

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

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

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

happy

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

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

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

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

個人意見哈^-^

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

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

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

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

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

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

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

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

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

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

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

但是在外部,定義這樣的一個類型及變量:
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ù)類型啊!從來沒有見到過這樣的類型啊.
你所說的"當把void(int)類型的函數(shù)作為一個值來傳遞時，它自動退化為void(*)(int)指針類型。"應(yīng)該是指,用它來定義變量的時候,這個變量就成了函數(shù)指針類型的了?

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

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

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

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

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

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

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

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

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

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

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

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

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等的操作,但我不明白這是什么意思;-( 我還沒學32位下的匯編呢.

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

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

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

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

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

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

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

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

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

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

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