巢穴

@局外人 是正確的,靜態(tài)局部變量不會(huì)出現(xiàn)雙重構(gòu)造的情況。。

怎么沒有45 46 的答案
chenxiongqian@gmail.com

你倆的id換的我淚奔了

tcpv2很難看下去
不知為何,也不知從何時(shí)起越來越不喜歡厚重的書了

非常非常非常贊
非常非常非常有創(chuàng)意!

又要有一段時(shí)間的陣痛期
又不知道各家編譯器的全面支持會(huì)到何時(shí)
又可能出現(xiàn)新的語(yǔ)法糖
有的時(shí)候c++真讓人有無力感

@放屁阿狗
signal是王道
定義一個(gè)自己的signal好了

其他的更多是用于同步,其實(shí)不符合這個(gè)語(yǔ)意

我覺得你這樣寫挺好
做等能把輪詢變被動(dòng)的方案

我覺得還有一個(gè)有意思的語(yǔ)意
既然是從你這fork的,你必然關(guān)注啊
不然的話就沒從你這fork的意義了

我是回那個(gè)說神話的人....
@千暮(zblc)

國(guó)內(nèi)頂尖公司的招聘并不算難
具體還是要看職位

有木有實(shí)際的測(cè)試數(shù)據(jù)可供參考啊

另外我個(gè)人覺得對(duì)于這個(gè)input buffer，我覺得它可一直擴(kuò)展不見得是好事
如果應(yīng)用層真處理的很慢，造成buffer增長(zhǎng)到內(nèi)存吃不消的時(shí)候還是很尷尬的
個(gè)人覺得還是有一個(gè)上限，把大于上限的阻塞于TCP的好

ls的回復(fù)太惡搞了
北京微軟好幾個(gè)地兒啊，具體哪個(gè)地兒啊

真的超贊
算法導(dǎo)論最重要的是習(xí)題啊。:)

我又2了。。沒仔細(xì)看題。。。真的要檢討了。。
同好奇。。

你可以把一個(gè)handle比喻成一個(gè)內(nèi)核對(duì)象在內(nèi)核中的數(shù)組索引，當(dāng)然，也許這個(gè)handle是索引處理過的東西
內(nèi)核對(duì)象身上自然存儲(chǔ)的有它相關(guān)的一些資源，屬性或信息

贊一個(gè)= =昨天沒仔細(xì)看題意。。我又2了。。
返回了m_pB做類型轉(zhuǎn)換的時(shí)候產(chǎn)生的臨時(shí)變量的ref,就像ls所說，孤魂野鬼，這并不是調(diào)用者對(duì)這個(gè)函數(shù)的期望

話說加個(gè)const,編譯器會(huì)做處理嗎？

加個(gè)const呢？

野指針……

應(yīng)該還是也指著啊

不怎么會(huì)玩五子棋和黑白棋的淚流滿面

在我看來這與直接new沒有什么不同，雖然被allocator包裝了
用這樣的函數(shù)已經(jīng)不是小心不小心的問題了

贊，記下

優(yōu)化這玩意放到后期慢慢重構(gòu)把

具體如何分配負(fù)載，那應(yīng)該實(shí)際問題實(shí)際處理吧

按接口分配，最后組裝，這就是標(biāo)準(zhǔn)的手術(shù)刀式的項(xiàng)目風(fēng)格吧
這種項(xiàng)目風(fēng)格，本就應(yīng)該每人只專注于自己的模塊，因?yàn)榻涌谝呀?jīng)確定，如果你還要去關(guān)注別的模塊，那只說明接口之間存在耦合，那就是設(shè)計(jì)問題。而且，這個(gè)時(shí)候你去關(guān)注過多的模塊，就會(huì)導(dǎo)致在設(shè)計(jì)時(shí)有過多的顧慮，顧慮多了問題自然也會(huì)多起來。
而且這種風(fēng)格應(yīng)該有一個(gè)經(jīng)驗(yàn)豐富的主治醫(yī)生來劃分模塊和設(shè)定接口，他是來掌控全局的，沒有這樣一個(gè)人，出問題的風(fēng)險(xiǎn)自然很大。
不過雖然如此，我也覺得的確不應(yīng)該對(duì)于代碼做出一些權(quán)限設(shè)置。
我雖經(jīng)也經(jīng)歷過代碼的權(quán)限的問題，但那大多是出于對(duì)代碼的保護(hù)，而且代碼大多是與設(shè)計(jì)模塊無關(guān)的底層基礎(chǔ)代碼。像博主所說的，對(duì)一些貫穿整體框架的代碼做出權(quán)限設(shè)置我還至今未結(jié)果。

ps.我也是一個(gè)喜歡先了解全局，再去深入細(xì)節(jié)的人

怎么得出的logN的復(fù)雜度。。

@素素
常量宏本質(zhì)上也只是0，1,2啊
在已編譯的可執(zhí)行程序中就是0,1,2
這個(gè)時(shí)候如果是動(dòng)態(tài)鏈接crt的dll，那自然有問題啊,這就是ABI的二進(jìn)制不兼容

@bneliao
f'(n) = g'(n) + h'(n)
h'(n)=0,且g'(n')=g'(n)+1,n'是n的后繼，為廣搜
h'(n)=0,且g'(n')=g'(n)-1,n'是n的后繼，為深搜
h'(n)=0,q'(n)為實(shí)際從起點(diǎn)至n點(diǎn)的路徑，分枝定界法

第二條不是虛表不起作用
是copy構(gòu)造函數(shù)中，編譯器把vtptr給換掉了，就像文中所說，tmpParent是CParent對(duì)象

@Heath
呵呵，笑而不語(yǔ)是何解？

迭代器失效？

看了那兩篇文章
第一篇文章的作者一直在拿本機(jī)的MTU與網(wǎng)絡(luò)MTU相比，然后設(shè)定成一個(gè)合適的值，已達(dá)到盡量不浪費(fèi)網(wǎng)絡(luò)資源的目的。而事實(shí)上，網(wǎng)絡(luò)的MTU應(yīng)該是會(huì)變化的，IP包的路線不是固定的。
哪怕IP包的路線固定了。
而且他所謂的網(wǎng)絡(luò)MTU是一條通路的MTU,自然只偏向于一條通路，對(duì)于別的通路自然不會(huì)有什么效果，甚至可能是反效果了

遞歸與遞推吧？

大佬？誰？

@空明流轉(zhuǎn)
恩。謝謝:) 受教啦

謝謝諸位大神哈，說的很好哈，的確是可以引入的，一切適情況而定。在次謝過了:)

@airtrack
恩。我就是這個(gè)想法，我認(rèn)為現(xiàn)在的這個(gè)項(xiàng)目進(jìn)度和規(guī)模，目前為了迎合單元測(cè)試，而做的這樣大規(guī)模的重構(gòu)，可能會(huì)引進(jìn)的問題會(huì)更多，穩(wěn)定性可能會(huì)不升反降。但因?yàn)槲业拇_從未使用過這個(gè)東西，所以對(duì)于我的想法不是很肯定，所以在這里咨詢一下各位大神哈

@空明流轉(zhuǎn)
呵呵，我主要是想更貼近于我們目前項(xiàng)目情況的一些觀點(diǎn)。如果是為回歸測(cè)試的話，是可以引入CppUnit,但是否有必要去做全面的單元測(cè)試呢？我覺得似乎是沒必要。想聽聽更多人的觀點(diǎn)。

可能我問的很膚淺，當(dāng)一段決定關(guān)閉TCP連接的時(shí)候，還去保證繼續(xù)可以接到一些信息的意義在哪，沒有上層邏輯，數(shù)據(jù)神馬用都沒有啊

對(duì)這個(gè)trick表示不解，求解……

給力

膜了個(gè)拜 啊

俺也受教了:)

看過2/3吧。。
表示這些看過。。（看過不代表都會(huì)啊。。）
計(jì)算機(jī)入門了……

@李現(xiàn)民
呵呵，是這樣的，是我粗心忘了這個(gè):)

@李現(xiàn)民
無非就是const的可能放在只讀數(shù)據(jù)段吧？
然后對(duì)于這個(gè)段設(shè)置只讀？

是這樣嗎？

這本書的確挺難的，是需要去啃的書
就像文中所說，如果你只是在用c++開發(fā)，不看這本書，完全可以的
但是你想榨取c++最后的那點(diǎn)性能提升，看它吧

您好，有一個(gè)問題
我現(xiàn)在還不是很了解rpc,只知道它是基于函數(shù)的遠(yuǎn)程調(diào)用
而corba是針對(duì)對(duì)象的
顯然在維護(hù)世界邏輯的時(shí)候，用corba應(yīng)該會(huì)顯得更簡(jiǎn)單一些
但是我看到使用rpc的人還是有很多的
我很好奇原因:)