可冰

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

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，不知道該用什么好。

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

謝謝大家的支持,我會繼續下去的。

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

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

但是這里的純虛析構函數是可以不用實現的，否則還如何來避免實例化，也更不成其為純虛函數了啊。

Jamie Zawinski的網站真是牛啊!佩服至極!

系統手冊[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終止當前指令的執行,而連續不斷地獲取下一字地址處的指令;當~nRESET恢復為高電平時,ARM920T執行下面的操作:
1. 拷貝當前PC和CPSR的值到R14_svc和SPSR_svc中.而保存過的PC和SPSR的值未定義(不確定).
2. M[4:0] <-- 10011,轉到Supervisor模式,設置CPSR中的I、F位為1(禁止中斷),并對T位清零(進入ARM狀態).
3. 設置PC從0x00處獲取下一條指令.
4. 在ARM狀態下執行指令.

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

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

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

看來還是知識不過硬啊!

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

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

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

注意是Reserved Byte Stored
在內存中是 68 61 70 70 79

happy

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

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

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

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

個人意見哈^-^

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

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

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

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

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

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

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

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

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

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

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

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

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

這又是怎么回事?

謝謝提醒.我已經將文件轉放在博客園上,現在可以下載了.

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

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

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

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

看了這個又稍微理解多一些了,關注中...

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

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

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

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

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

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

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

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

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中它們沒出現過,應該是正確的吧.

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

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

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

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

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

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

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

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

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

到現在我天天都在用它收發很多信的,可還是沒有發邀請的權限啊.
仍然郁悶的等待中.....