人生半路, 殺出個(gè)程序

release下的?

@欣萌
啊哦, 有眼不識(shí)泰山, 真遇到做編解碼器的了...

代碼沒(méi)看，但是要如lz所說(shuō)的話(huà)，好無(wú)厘頭的錯(cuò)誤啊。。。

這個(gè)是引用計(jì)數(shù)的，沒(méi)問(wèn)題。
想想看，如果這個(gè)函數(shù)沒(méi)有引用計(jì)數(shù)，那會(huì)帶來(lái)無(wú)數(shù)的問(wèn)題。

@欣萌
難不成您想自己做個(gè)ffmpeg？

@路過(guò)
ps：apr真的是做得很好：）

@路過(guò)
回訪，容我說(shuō)一句，lz這個(gè)東西寫(xiě)的確實(shí)不夠好，這個(gè)不用看高超的實(shí)現(xiàn)就能判斷。簡(jiǎn)單的說(shuō)就是這個(gè)實(shí)現(xiàn)“不能用”。但是也不能說(shuō)是垃圾吧？至少lz寫(xiě)的代碼整整齊齊，沒(méi)有注釋也很容易看懂，基本方法也對(duì)。

“垃圾”這種說(shuō)法，還是盡量別出現(xiàn)在這個(gè)站點(diǎn)比較好。

說(shuō)到底boost是用事先構(gòu)造單例對(duì)象的方法規(guī)避使用鎖。
看來(lái)不使用鎖和“使用時(shí)構(gòu)造”這兩個(gè)便利只能取一個(gè)，具體實(shí)現(xiàn)時(shí)要分析利弊了。

我覺(jué)得auto_ptr是C++里面典型的“因?yàn)樵O(shè)想太過(guò)宏偉，從而產(chǎn)生問(wèn)題”的范例。

事實(shí)上大多數(shù)人為什么會(huì)想到用一個(gè)包裝過(guò)的指針？害怕內(nèi)存泄漏。那么我們需要的就是一個(gè)確定會(huì)在某一個(gè)域結(jié)束時(shí)把自身攜帶對(duì)象析構(gòu)掉的指針，就這么簡(jiǎn)單。那么我們就實(shí)現(xiàn)一個(gè)沒(méi)有賦值功能的auto_ptr就好了，一了百了。

而且我覺(jué)得這里面有一個(gè)邏輯問(wèn)題：假設(shè)我們?cè)诖罄ㄌ?hào)開(kāi)始處建立一個(gè)攜帶對(duì)象的指針，并且確定在大括號(hào)結(jié)束的時(shí)候?qū)ο髸?huì)析構(gòu)掉，那我們有什么理由把它傳遞給大括號(hào)之外的代碼呢？

debug的時(shí)候用的吧？

你不覺(jué)得把讀取的每個(gè)單位的尺寸和單位數(shù)分開(kāi)可讀性更高么？一個(gè)函數(shù)調(diào)用的實(shí)參中出現(xiàn)了乘法，第一眼看上去肯定會(huì)覺(jué)得費(fèi)解。

而且往高里說(shuō)這是個(gè)設(shè)計(jì)理念問(wèn)題，作為一個(gè)接口，讓用戶(hù)越少思考越好。

sizeof(XXX) * count = 總字節(jié)數(shù)，這是你想出來(lái)的，想這個(gè)問(wèn)題難道不需要費(fèi)力么？

第二個(gè)問(wèn)題嘛，通用的解決方案是“優(yōu)先級(jí)”

自動(dòng)加一句日志指令？這個(gè)很難想象。。。倒是可以用宏實(shí)現(xiàn)。

我猜想如果沒(méi)有(void)ERROR_##msg;這句，編譯器會(huì)把前面的變量定義優(yōu)化掉從而斷言失效？

只是猜想。

兩點(diǎn)不同意見(jiàn)：

1.
Mutex::~Mutex()
{
...
throw MutexError("pthread_mutex_destroy error");
...
}

這個(gè)絕對(duì)不可以有。。。

2.我覺(jué)得lock和unlock之間的代碼不安全，如果拋出異常可能導(dǎo)致死鎖。

—— xml和log

你說(shuō)的這個(gè)問(wèn)題， 是不能靠語(yǔ)言提供標(biāo)準(zhǔn)庫(kù)來(lái)做的。
很簡(jiǎn)單， Qt用std::string了嗎？ ACE用了嗎？ MFC用了嗎？

=============

這一句說(shuō)的太好了，C++很大一部分的混亂的起因不是“沒(méi)有標(biāo)準(zhǔn)實(shí)現(xiàn)”——當(dāng)然很多時(shí)候確實(shí)沒(méi)有標(biāo)準(zhǔn)實(shí)現(xiàn)，而是大家都要去實(shí)現(xiàn)。而且，那boost來(lái)說(shuō)，boost曾經(jīng)拒掉一個(gè)log方面的庫(kù)，但是就算是boost里面有這個(gè)庫(kù)，有多少人會(huì)去用？很多時(shí)候不是主觀上不喜歡用，而是說(shuō)boost，包括像stl這種東西，它們的編程哲學(xué)太強(qiáng)勢(shì)，并且經(jīng)常迥異于我們慣常的代碼。

加法滿(mǎn)足交換律

恩，上面那個(gè)回復(fù)里用“指針的指針”規(guī)避對(duì)象指針和函數(shù)指針的大小不一樣這一點(diǎn)，挺好的。

給樓主提個(gè)建議: 這樣的文章可能對(duì)寫(xiě)作者來(lái)說(shuō)意義和樂(lè)趣都很大, 但是作為一個(gè)讀者, 我實(shí)在感覺(jué)不出來(lái)"閱讀的快感".

這種時(shí)候最好加上一個(gè)#pragma pack命令，對(duì)應(yīng)于gcc好像是__attribute吧。

普遍的通用方法.

@yew98
同意, 排除寫(xiě)日志動(dòng)作的互斥性還是得考慮一下.

@forgot
好啊, 你幫大家寫(xiě)一個(gè)吧, 我反正寫(xiě)不出來(lái).@yew98

再來(lái)個(gè)迭代器吧, 這樣就能方便使用那些算法了.

@陳梓瀚(vczh)
哦, 你說(shuō)的是對(duì)的, 中看走眼了, 看見(jiàn)123就下意識(shí)的一位是尺度.

@陳梓瀚(vczh)
模板參數(shù)只能是常量的前提下, 這樣搞和 intArray[3][4][5];有啥區(qū)別?

謝謝分享，很通用的設(shè)計(jì)，VCL類(lèi)庫(kù)里的TThread類(lèi)基本就是這個(gè)樣子。

說(shuō)一點(diǎn)個(gè)人的想法：我自己寫(xiě)的類(lèi)也差不多是這樣，不過(guò)有一點(diǎn)差別：我個(gè)人認(rèn)為“線程”和“線程要跑的任務(wù)”是兩個(gè)東西，前者是內(nèi)核對(duì)象（抱歉，我總是改不了用win32本位思考）的抽象，跟具體功能沒(méi)關(guān)系，后者是功能的抽象，跟具體程序有關(guān)系。

所以我傾向于把static THREAD_API Routine(void* arg)分離出來(lái)，成為一個(gè)ITask接口。

這樣做還有一個(gè)好處，當(dāng)Thread跑完了Task的代碼后可以阻塞在那里等待跑別的Task。

另外我對(duì)protobuf也蠻感興趣的，但是我有點(diǎn)看不懂那個(gè)東西，功力太淺：）

這個(gè)東西的難度ms是解決"閃"的問(wèn)題.

1 這個(gè)東西能實(shí)現(xiàn)邏輯層和UI層在不同線程里的事件機(jī)制? 沒(méi)看出來(lái).

2 這么執(zhí)著的降低耦合,應(yīng)該是比較大的程序里才有用吧? 但是模板機(jī)制只能在一個(gè)模塊里使用,這個(gè)限制還是比較大的.

3 把耦合降到最小,似乎需要加一層"事件解釋機(jī)制". 邏輯和UI的最大耦合不在于回調(diào)的形式上,而在于事件解釋機(jī)制的分散.邏輯層發(fā)生的事件是諸如"底層數(shù)據(jù)更新"的事件,UI層的響應(yīng)是"ListView重載入" 這樣的, 把這些之間的解釋和映射放到一起,無(wú)論什么形式的回調(diào)機(jī)制都可以.

純個(gè)人感覺(jué), 不要相信:)

這種只讀內(nèi)存的代碼不會(huì)有什么問(wèn)題。而且你這個(gè)代碼訪問(wèn)的是靜態(tài)內(nèi)存sum。

@absolute
呵呵，我又來(lái)了：P
在只有debug使用的情況下，選個(gè)大差不差的常數(shù)就好了，狼不浪費(fèi)其實(shí)也沒(méi)什么關(guān)系，我自己要是搞這種東西一般都是為了查查內(nèi)存泄露什么的

@expter
你這個(gè)重載的new其實(shí)不就是個(gè)mempool么？只不過(guò)分配的空間大小是個(gè)常數(shù)而已。

內(nèi)存池這個(gè)東西，除了在頻繁的申請(qǐng)和釋放小塊內(nèi)存的情況下以外，似乎也沒(méi)有多大效率優(yōu)勢(shì)吧。如果單單為了防治內(nèi)存泄漏啟用內(nèi)存池，會(huì)不會(huì)有點(diǎn)得不償失？而且對(duì)于服務(wù)類(lèi)軟件，僅僅在軟件結(jié)束運(yùn)行的時(shí)候成功釋放掉所有內(nèi)存這種防泄漏方式，是很不夠的，因?yàn)榉?wù)一般會(huì)運(yùn)行很長(zhǎng)時(shí)間。

不過(guò)內(nèi)存池在調(diào)試的時(shí)候倒是蠻有用的。

那些關(guān)于模板的標(biāo)準(zhǔn)問(wèn)題我也不知道，但是那些關(guān)于引用的，是符合標(biāo)準(zhǔn)的。現(xiàn)行的標(biāo)準(zhǔn)（非c++09）規(guī)定右值只能綁定到const引用上。

編譯器崩潰是bcb的bug，并且沒(méi)有解決方案，我找過(guò)很久，根本沒(méi)有。

關(guān)于那個(gè)我根本看不懂的宏，更不知道了。。。

總的來(lái)說(shuō)，像你這種情況，我建議你用BCB制作界面，把功能代碼全用MSVC搞成dll。

哈哈，有此經(jīng)歷人飄過(guò)。這種分號(hào)一般都是不小心打上的然后編譯器檢查不出來(lái)。

到底iter++和++iter有什么區(qū)別呢？
除了重載的操作符參數(shù)類(lèi)型不一樣以外。

你一個(gè)線程select幾十個(gè)不就行了？

@金慶
要是把本該是參數(shù)的變量轉(zhuǎn)換成成員變量,會(huì)帶來(lái)更多的問(wèn)題:
如何初始化? 你怎么設(shè)置它? 設(shè)置了以后能不能隨便改動(dòng)? 要不要加鎖?...

而且你每次改動(dòng)這個(gè)參數(shù)的類(lèi)型都要找到頭文件里再改一遍, 很麻煩.

本質(zhì)上說(shuō), 一個(gè)只與某個(gè)方法有關(guān)的變量, 為什么要讓類(lèi)知道他的存在?

對(duì),應(yīng)該需要幾個(gè)用幾個(gè)

@mybios
一維的顯示器？您沒(méi)事吧？

另外，這個(gè)投影是成立的，4維投3維，三維再投成2維。

這個(gè)結(jié)果是動(dòng)畫(huà)還是靜止的？

有一個(gè)紀(jì)錄片專(zhuān)門(mén)講述這方面，好像叫dimensions，你可以去找找

@黑色靈貓
良好的架構(gòu)和程序員自身的習(xí)慣比什么機(jī)制都來(lái)的好,正解。可是也沒(méi)好到連智能指針這種幾乎沒(méi)什么壞處的東西都丟棄吧？

這個(gè)看起來(lái)是客戶(hù)端用的dll的一部分吧？

從代碼沒(méi)看出來(lái)“遠(yuǎn)程對(duì)象調(diào)用”這個(gè)主題啊，感覺(jué)就是把client和server之間的通信協(xié)議封裝起來(lái)了，client看到的是一個(gè)接口，或者說(shuō)proxy類(lèi)，調(diào)用它的方法，它就按照一定的通信規(guī)約把命令傳給server，再接收server傳過(guò)來(lái)的結(jié)果，是這個(gè)意思吧？

這個(gè)還真么注意到，放在命名空間里也會(huì)替換么？

呵呵，這可能就是我不敢用boost的原因。
而且公司的人也不讓用，連模板都不讓用。

工作線程里最好還是不要做與界面相關(guān)的工作。這樣很容易鎖死，有時(shí)候根本注意不到，比如一不小心在工作線程里彈出個(gè)messagebox什么的。還是跟主線程發(fā)消息解決比較安全。

另外也很難搞清楚界面控件的線程安全性。

要想不攜帶void *參數(shù)，還是得用模板。