release下的?

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

代碼沒看，但是要如lz所說的話，好無厘頭的錯誤啊。。。

這個是引用計數的，沒問題。
想想看，如果這個函數沒有引用計數，那會帶來無數的問題。

@欣萌
難不成您想自己做個ffmpeg？

@路過
ps：apr真的是做得很好：）

@路過
回訪，容我說一句，lz這個東西寫的確實不夠好，這個不用看高超的實現就能判斷。簡單的說就是這個實現“不能用”。但是也不能說是垃圾吧？至少lz寫的代碼整整齊齊，沒有注釋也很容易看懂，基本方法也對。

“垃圾”這種說法，還是盡量別出現在這個站點比較好。

說到底boost是用事先構造單例對象的方法規避使用鎖。
看來不使用鎖和“使用時構造”這兩個便利只能取一個，具體實現時要分析利弊了。

我覺得auto_ptr是C++里面典型的“因為設想太過宏偉，從而產生問題”的范例。

事實上大多數人為什么會想到用一個包裝過的指針？害怕內存泄漏。那么我們需要的就是一個確定會在某一個域結束時把自身攜帶對象析構掉的指針，就這么簡單。那么我們就實現一個沒有賦值功能的auto_ptr就好了，一了百了。

而且我覺得這里面有一個邏輯問題：假設我們在大括號開始處建立一個攜帶對象的指針，并且確定在大括號結束的時候對象會析構掉，那我們有什么理由把它傳遞給大括號之外的代碼呢？

debug的時候用的吧？

你不覺得把讀取的每個單位的尺寸和單位數分開可讀性更高么？一個函數調用的實參中出現了乘法，第一眼看上去肯定會覺得費解。

而且往高里說這是個設計理念問題，作為一個接口，讓用戶越少思考越好。

sizeof(XXX) * count = 總字節數，這是你想出來的，想這個問題難道不需要費力么？

第二個問題嘛，通用的解決方案是“優先級”

自動加一句日志指令？這個很難想象。。。倒是可以用宏實現。

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

只是猜想。

兩點不同意見：

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

這個絕對不可以有。。。

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

—— xml和log

你說的這個問題， 是不能靠語言提供標準庫來做的。
很簡單， Qt用std::string了嗎？ ACE用了嗎？ MFC用了嗎？

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

這一句說的太好了，C++很大一部分的混亂的起因不是“沒有標準實現”——當然很多時候確實沒有標準實現，而是大家都要去實現。而且，那boost來說，boost曾經拒掉一個log方面的庫，但是就算是boost里面有這個庫，有多少人會去用？很多時候不是主觀上不喜歡用，而是說boost，包括像stl這種東西，它們的編程哲學太強勢，并且經常迥異于我們慣常的代碼。

加法滿足交換律

恩，上面那個回復里用“指針的指針”規避對象指針和函數指針的大小不一樣這一點，挺好的。

給樓主提個建議: 這樣的文章可能對寫作者來說意義和樂趣都很大, 但是作為一個讀者, 我實在感覺不出來"閱讀的快感".

這種時候最好加上一個#pragma pack命令，對應于gcc好像是__attribute吧。

普遍的通用方法.

@yew98
同意, 排除寫日志動作的互斥性還是得考慮一下.

@forgot
好啊, 你幫大家寫一個吧, 我反正寫不出來.@yew98

再來個迭代器吧, 這樣就能方便使用那些算法了.

@陳梓瀚(vczh)
哦, 你說的是對的, 中看走眼了, 看見123就下意識的一位是尺度.

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

謝謝分享，很通用的設計，VCL類庫里的TThread類基本就是這個樣子。

說一點個人的想法：我自己寫的類也差不多是這樣，不過有一點差別：我個人認為“線程”和“線程要跑的任務”是兩個東西，前者是內核對象（抱歉，我總是改不了用win32本位思考）的抽象，跟具體功能沒關系，后者是功能的抽象，跟具體程序有關系。

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

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

另外我對protobuf也蠻感興趣的，但是我有點看不懂那個東西，功力太淺：）

這個東西的難度ms是解決"閃"的問題.

1 這個東西能實現邏輯層和UI層在不同線程里的事件機制? 沒看出來.

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

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

純個人感覺, 不要相信:)

這種只讀內存的代碼不會有什么問題。而且你這個代碼訪問的是靜態內存sum。

@absolute
呵呵，我又來了：P
在只有debug使用的情況下，選個大差不差的常數就好了，狼不浪費其實也沒什么關系，我自己要是搞這種東西一般都是為了查查內存泄露什么的

@expter
你這個重載的new其實不就是個mempool么？只不過分配的空間大小是個常數而已。

內存池這個東西，除了在頻繁的申請和釋放小塊內存的情況下以外，似乎也沒有多大效率優勢吧。如果單單為了防治內存泄漏啟用內存池，會不會有點得不償失？而且對于服務類軟件，僅僅在軟件結束運行的時候成功釋放掉所有內存這種防泄漏方式，是很不夠的，因為服務一般會運行很長時間。

不過內存池在調試的時候倒是蠻有用的。

那些關于模板的標準問題我也不知道，但是那些關于引用的，是符合標準的。現行的標準（非c++09）規定右值只能綁定到const引用上。

編譯器崩潰是bcb的bug，并且沒有解決方案，我找過很久，根本沒有。

關于那個我根本看不懂的宏，更不知道了。。。

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

哈哈，有此經歷人飄過。這種分號一般都是不小心打上的然后編譯器檢查不出來。

到底iter++和++iter有什么區別呢？
除了重載的操作符參數類型不一樣以外。

你一個線程select幾十個不就行了？

@金慶
要是把本該是參數的變量轉換成成員變量,會帶來更多的問題:
如何初始化? 你怎么設置它? 設置了以后能不能隨便改動? 要不要加鎖?...

而且你每次改動這個參數的類型都要找到頭文件里再改一遍, 很麻煩.

本質上說, 一個只與某個方法有關的變量, 為什么要讓類知道他的存在?

對,應該需要幾個用幾個

@mybios
一維的顯示器？您沒事吧？

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

這個結果是動畫還是靜止的？

有一個紀錄片專門講述這方面，好像叫dimensions，你可以去找找

@黑色靈貓
良好的架構和程序員自身的習慣比什么機制都來的好,正解。可是也沒好到連智能指針這種幾乎沒什么壞處的東西都丟棄吧？

這個看起來是客戶端用的dll的一部分吧？

從代碼沒看出來“遠程對象調用”這個主題啊，感覺就是把client和server之間的通信協議封裝起來了，client看到的是一個接口，或者說proxy類，調用它的方法，它就按照一定的通信規約把命令傳給server，再接收server傳過來的結果，是這個意思吧？

這個還真么注意到，放在命名空間里也會替換么？

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

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

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

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