您知道Linux下C语言编程的一些注意事项吗_教育中国
云風的 BLOG: 一個 C 接口設計的問題
一個 C 接口設計的問題
C 語言在本質上，參數傳遞都是值傳遞。不像 Pascal 和 C++ 可以傳引用。這一點，使得 C 語言可以保持簡單的設計，但另一方面也頗為人詬病。
因為性能問題，指針不得不被引入。可以說，用 C 語言實現的軟件，其實現的 Bug 90% 以上都來至于指針，應該是沒有夸大了。當然設計引起的問題或許更為關鍵一些，那些于指針無關。
糾結于性能問題上，層次比較低?？?C 語言就是一個活躍在較低層次的語言，一旦你選擇用它，就不得不關心性能問題。反過來，把 C 模仿成更高級的語言，倒是有點畫蛇添足了。好了，讓我們來看個實際的涉及參數傳遞的相關問題，用 C 語言該如何設計。
最近同事在做一個類似 Protocol Buffers 的東西。這個東西做好并不容易，設計上尤為困難。其中的設計難點：設計一個合適的 DSL (領域專用語言) 我們討論過很久，也分析了好幾天，但今天不打算談了。揀個小東西說：當我們把一個二進制結構化數據塊解析出來，傳遞到 C 語言中，讓 C 語言可以方便的訪問數據結構時，接口如何設計？
?
這個問題在目標語言不是 C 而是更高級的語言（尤其是有 gc 機制的語言）時，都不是問題?？?C 語言本身是沒有對象概念的。
C 語言有結構，但是不具備描述動態長度的能力；沒有字符串，只有定長的字符數組；甚至沒有多維數組，只有一維數組的數組。
C 函數的參數及返回值可以是結構，但在接口設計中，或許是因為值傳遞，以及考慮 ABI 的簡潔性的關系，常常使用結構指針。返回結構指針往往有生命期管理的苦惱。即使到了 C++ 里，允許返回結果/對象了，可所謂返回值優化也是件相當讓人困擾的事情（如果你打算完全放棄了解語言的細節，無視細微處的性能問題。那么，為什么不考慮使用 Java 或是 Python ，無論什么都比選擇 C++ 強）。
對于返回一組復雜數據，通常的辦法有些什么？
最常用的方法是，調用者分配空間，傳遞給處理函數。由處理函數反向填寫結構內容。這樣的好處是，調用者可以選擇把空間分配在棧上還是堆上。一點小提示：在語法上，C 語言允許你把一個數組當成指針來傳遞。所以你可以定義一個長度為 1 的結構數組類型。用起來好看一些。具體見標準庫中的 setjmp 的定義。不過作為我個人的理念來說，不太主張在 C 語言設計的軟件中，為了減少幾次鍵盤輸入，而使用過多的語言特性。
這個方式的缺點是，你很難讓調用者定義不定的數據結構。尤其是在結構里還有對別的結構的引用。
跟這個相似的是接收字符串。最典型的例子是標準庫中的 fgets ，提供一個接收緩沖區的地址指針，和一個緩沖區大小。（注：gets 則是一個失敗的設計）同樣在 Windows 的 API 中，也隨處可見這樣的例子。
第二，就是由函數自己分配內存，交給調用者去釋放。大家只需要約定內存管理的接口即可。標準庫中的 strdup 就是這樣做的，同樣的還有 readline 庫中的 readline 。C 語言統一使用 malloc 管理內存，不像 C++ 提供了更靈活（更難控制，更容易出問題？）的 new 操作符重載。所以，給出這個約定并不會增添太多的麻煩。btw, 由于微軟 VC 的 CRT 對 malloc 等實現的過于糟糕，導致很多 Windows 的軟件自行實現內存管理器?；蛘咴趲熘虚_放自定義內存管理器注入的接口。這其實有點越俎代庖了。gcc 提供的 CRT 里， malloc 性能就相當不錯了。
缺點呢？內存只能從堆上分配；而且增加了內存泄露的隱患；設計角度上講，也不太干凈。對于復雜數據結構，這個方法也無能為力。C 語言里并沒有所謂析構函數的說法。
作為對第二點的一種補充方案，用的人就鳳毛麟角了。那就是給你的系統加入 gc 。實際上，就是約定另一種內存管理方法。我們的項目部分模塊在用，效果還不錯。gc 庫已經開源，請參考這里。如果信不過這套東西，可以考慮 COM 的機制：增減引用。COM 旨在建立一種對象模型，可惜 C 語言中沒有對象的概念，在 C 的層面使用 COM ，痛苦了一些。對于粒度比較小的東西，性能也將是問題。
第三種，用的人也比較多。就是在函數內部開一塊靜態空間，用于數據返回。返回的指針指向的數據的生命期可以保證到下次調用同一函數之前。靜態空間可以聲明在數據段里，也可以在程序初始化時從堆上分配出來，這樣利于在空間不夠的時候擴展。至于這塊靜態空間什么時候釋放的問題，不用太操心。即使不去釋放它們也不用內疚。操作系統會幫你回收的，還會比你干的更出色。C 是為了實現 UNIX 而誕生，而 UNIX 的哲學就是，編寫簡單的程序專心干好自己的事，讓更高層次的程序（通常是 shell 或動態語言）去組合它們，讓操作系統去管理它們。在 Windows 上，Unix 編程哲學未必有用，但大原則沒錯的。
這個方案有另外一個問題，就是函數不可重入，且有線程安全問題。重入問題可以想辦法避免。線程安全可以用 TLS 解決。老實說，我個人不看好在 C 語言中使用多線程解決問題。多線程也是違背 Unix 哲學的。如果你有幾件事情需要協調起來做，使用多進程；如果你有幾百件事情需要同時來做，考慮換個思路，玩玩 Erlang 啥的。
?
?
回到今天我們面臨的問題。用一種 DSL 來描述一個數據結構（比 C 的結構表達能力更強的），然后生成對應語言的解析庫。如果目標語言是 C 的話，我們生成的代碼如何返回對 C 程序員友好的結構化數據呢？
這讓我想到了 MySQL 的 C 語言接口。很多初學 C++ 的程序員，很喜歡把那些 C 接口“封裝”成“漂亮”的 C++ 接口。直接返回 vector 套 map 的多層模板實例。不知道有多少人干過？前幾年我帶實習生的時候反正見過不少。如果同學你現在醒悟了，明白這是件巨傻X 的事情，那么握握手，我們有共同理念；否則（C++ 封裝以后不是很“酷”嗎？），我們暫時沒有共同語言了。
我不是想說 MySQL 的 C 接口設計的很好，不過是中規中矩。只是 C++ 不是 C ，C 也不是 C++ 。（話說，上面提到的 C++ 封裝，我也不認為是正確的使用 C++ ）反復提及 C++ ，是因為，我發現今天很大比例的 C 程序員其實是從 C++ 開始啟蒙的，而不是相反。把 C++ 當成 C 用的危害其實比不上把 C 當成 C++ 用。前者不過是把汽車開到自行車的速度，至少不怕摔跤了，跑起來還能安全點；而后者，非要把自行車踩到高速公路中間，遲早非撞死不可。
最方便 C 程序使用的莫過于傳入一個結構指針，讓庫去解析數據，填寫這個結構了。
但是，如果結構里有字符串、不定長數組（通常會根據前面解析出來的數據決定后面的長度，對于 C 的編程技巧來說，允許把結構體的最后一個數組的長度設為 0 ，假設成不定長的，從而減少一次間接的指針引用。但是對于結構中有多個不定長數組則無法使用這個技巧。）等等的話，就很難避免指針了。
數據中一旦出現指針（間接引用別的數據），就有內存管理問題。
最開始，考慮過一個很 C++ 的方案，傳入一個內存管理器。這種設計在 STL 里就有。所有 STL 的容器都可以指定一個 allocator ，供靈活的管理內存。前幾年我倒是認為這是個相當巧妙的東西。沒有細想，自定義分配器最終有多大的意義？自定義內存管理器，很大程度上是因為效率因素引起的。但性能問題永遠不是根本問題。制作軟件是為了達到特定的目的，而軟件開發的問題更多的是是解決復雜度問題。往往復雜度帶來的性能問題更加嚴重。然后為了解決復雜度帶來的性能問題去引入更高的復雜度，出現惡性循環的可能性非常之大。
即使我們傳入的內存管理器（或是直接使用 CRT 里的 malloc，但這樣就沒可能利用堆棧分配空間了），還會面臨新問題，如何回收結構中間接引用的數據。引入析構函數指針？OMG 。
后來，我們設想使用一個內部靜態空間，所有的解析結果都分配在內部，自我管理。這些空間還可以復用。大部分解析結果也就是臨時用用，這樣做很方便。而且調用者不用太關心數據的生命期。
但是，一旦調用者需要把結果（一個復雜結構）保存一段時間的話，他就遇到困難。
當然，也可能不是困難。當我們面對這個設計難點時，都應該向上考慮一層，究竟這是一個問題嗎？我們需要這么用嗎？
調用者可以自己遍歷這個數據結構，把他需要的數據，以自己的方式復制出來，組織起來。他們需要的是數據，而不是對數據結構完全的拷貝。
仔細考慮過以后，我們還是發現，保留完整的數據結構是有意義的。不像 C++ ，C 沒有對象賦值操作符重載這種語法糖，我也不喜歡用宏去模擬一個出來。增加一個拷貝函數指針其實和增添一個析構函數一樣，對 C 來說，不那么漂亮。（當然，同時增加了開發量，我們需要編寫更多的代碼自動生成器）
最終，我們采用了由調用者傳入緩沖區指針的方案。要求解析器生成的數據結構放在一塊連續的內存空間上。這樣，調用者就可以把指針直接定義成最終方便訪問的結構或聯合。但是提供更充裕的內存空間，存放那些內部引用的數據（比如字符串）。
因為結果數據區是由調用者提供，就不存在數據復制移動引起的指針調整問題（調用者可以自己先分配好）。
最后一個問題是，如何讓調用者估算數據接收區的大小呢？
很多 Windows API 可以通過兩次調用來完成，第一次空調用計算需要的緩沖區大小，第二次真的去填寫數據。根據實際需求分析過之后，我認為在我們這個模塊的應用上，這樣做是多余的。我們盡可以讓用戶隨便給一個估算大小去處理數據，一旦空間不夠，返回錯誤信息。讓用戶自己擴大緩沖區，重新調用一次即可。
btw, 不斷重試是我們最終認可的最 KISS 的方案。一開始，我們認為讓處理程序自己分配內存，并自己使用 realloc 更好。后來發現，完全是多余的設計。因為，解析二進制流是 O(1) 的操作，不比估算長度慢；而往往調用者都能正確估算接收區應有的長度，即使簡單的每次兩倍的方法擴展接收區大小，也不會浪費多少處理時間。即使他們需要精確分配結果需要的內存塊，盡可以用一個足夠大的公用緩沖區接收，然后得到長度信息，重新在特定內存上重來一次即可。
?
?
寫累了。想表達的也表達完了。今天到此為止。 :D
ps. 前幾天寫了一篇關于 一種對漢字更環保的 Unicode 編碼方案 ，我昨晚花了兩小時寫了個簡單的 C 實現?？梢园?UTF-8 或 UTF-16 轉換到我自己定義的暫且命名為 UTF-C 的編碼上，也可以轉回來。代碼用的行數比預想的要多一些，因為我低估了 UTF-8 的處理復雜度（其實也不復雜啦）。
有興趣的同學可以看這里。
Comments
開年以來讀到的第一篇雄文，如飲烈酒，甘冽有勁。
strdup是posix的, 不是c庫.呵呵
哈哈，我們有共同點語言，我大膽地猜測，風云大哥一定更喜歡使用寫codegen來解決語言的不足，而不是去依賴某一語言的特性。
方法三稍微修改，函數內部靜態空間每線程一個，與當前線程(ID)捆綁。實現上以線程ID為key，在數組或HashMap中存放緩存，實現頗為簡單，性能幾乎絲毫不損，也可解決文中大部分問題，唯是不可重入。不過正如云風所說，這個問題可能不是問題。
C 語言標準并沒有特別限制返回值不能是什么，所以 C 是允許返回struct 作為一種返回復雜數據的方案的。
不知道被以前看過的哪本書誤導，我覺得返回 struct 是 C++ 對 C 的一個擴展。（其實不是）
感謝指出這個錯誤的朋友，我今天仔細核對了 ISO C90 和 ISO C99 標準。:D
您的語言表達能力有待提高啊。。。
"這讓我想到了 MySQL 的 C 語言接口。很多初學 C++ 的程序員，很喜歡把那些 C 接口“封裝”成“漂亮”的 C++ 接口。直接返回 vector 套 map 的多層模板實例。不知道有多少人干過？前幾年我帶實習生的時候反正見過不少。如果同學你現在醒悟了，明白這是件巨傻X 的事情，那么握握手，我們有共同理念；否則（C++ 封裝以后不是很“酷”嗎？），我們暫時沒有共同語言了。"
呵呵，我也這樣干過。不過，沒辦法，誰叫咱，那時候剛學會
c++,不管什么東西，都要用我的c++這把小斧頭試試啊。
windows api的調用歷來就是這么做的
為什么說C函數不能返回結構？
為什么不看看xdr? sun rpc中的數據序列化方式，如果嫌它在線程安全上問題太多，那么看看cdr?C++和java都在用它。corba的idl和sun rpc的xdr就是兩個很好的用DSL定義數據然后交給C語言去解析的例子。我覺得你所討論的這些，在它們的實現上全有答案。
至于allocator，我只在loki中看見它為小對象設計過，專用于小于64bits的小對象的分配。我覺得這方面是花力未必討好的事情。有時間可以做點別的優化。哦，可以借其做內存泄露的調試器。
至于數據接收區的大小，我覺得stl的stringstream以及string/vector這些都做的很好，根據需求自動增長，還可以讓程序員可以靈活的預留空間。但是可惜沒有realloc。不知道你的應用具體是什么情形，如果每次都是delete/new而沒有realloc,對于性能影響大不。
感覺就是在說fgets嘛
這篇文章提了一個問題：如何用C語言接收被調用函數返回的數據塊？
答案是：調用者分配內存，然后傳指針給調用函數。被調用者往里面填數據。
簡單的說就是：去超市買東西得自備購物袋。
當初我以為指針的數值等于指針指向的地址
后來才發現這兩是不等的。
我到現在還是沒搞清楚這兩者的關系。
只是 知道 指針的數值的地址包含有個指針頭數據才到指針真正的數據的地址。
有沒有語法或函數得到一個指針指向數據的長度？
感覺寫得很混亂，看得不是很明白，說的是對2進制數據的描述？
bioware的很多游戲文件都是2進制描述的，比如.tlk，從博德1開始發展到現在也沒淘汰，可以描述一段對話的文本（字符串），配音文件（字符串），時間軸（浮點），顏色什么的，實現也簡單，像元數據，先用一個數據結構描述數據結構的結構，然后就是按字節依次填充了
我們公司的模塊間數據接口多數是這種類似fread的方案。不過看RADVISON的代碼就喜歡傳分配器了。
GLib就有點用C寫C++的感覺。
傳分配器也可以"要求解析器生成的數據結構放在一塊連續的內存空間上"啊，只不過，真的有點怪，明明傳了個分配器，卻又約定只能調用一次-_-!或者傳一個類似于realloc的分配器？
呵呵，最終的解決辦法 省心啊， 時間真的很寶貴，省出的時間可以泡泡妞，灌灌水， 這才叫生活
pool 是一個內部解決方案，能不暴露出來就不暴露出來。否則，就需要記住兩個東西：1. 結構的地址, 2. pool . 并且要記住兩者的關系。
如果要用的話，最好和別的部分正交化。比如，先創建后 pool 傳遞 buffer 指針進去。
至于 pool 的伸展能力，在這里不是必須的。文中已有講述。遵循能減則減的原則，就可以去掉了。
其實在堆上還是在棧上的問題，即使傳分配器，也是都可以兼顧到的 ：） 只要愿意弄點奇技淫巧的話。
傳分配器的大問題是，復雜的數據結構是多次分配的，而最終需要一次釋放。這限制了分配器的設計（必須設計成 pool 那種，而不能是 C 標準的 malloc ）
雖然內存管理器等方案也不算壞，但從KISS上說，傳內存確實用起來最簡單，也靈活。（注意云風多次強調，內存可以在堆里分，也可以在棧上分，似乎要達到這個目地傳內存就是唯一的方法了）
哈哈，新年好，特別謝謝上個星期云風大哥幫我抽中的豆漿機，豆漿很好喝，呵呵。
平時也一直在用c語言，說些我的看法吧：
1、c是用來做一些底層和性能要求較高的事情，如果不是很注重性能的話，沒必要用它。
2、c是可以傳結構體的。c中對于不定的結構體，可以用void指針。
4、對于像nginx這類代碼，可以借鑒一下它里面的pool的概念。也就是對于不同的生存期的對象定義不同的pool，在對象開始時，分配一定的內存，在對象存活時，可以從這個pool中分配內存，不夠的話，擴大這個pool。在對象消亡時，釋放這個對象的pool。pool底層的實現其實都是malloc來做的。不過它的特定環境是session這類有特定生存期的對象，與程序的原有設計關系很大，如果是通用的內存分配，像這類東西就沒法做到了。
GLib很多模塊都是傳構造和析構函數指針進去，或者至少傳析構指針
至于說的引入析構函數指針的問題，一般情況下，內存都由內存分配器管理，不同生命期的對象使用不同的管理器，如果只牽涉的內存的話，我覺得要注冊析構的情況是很少的
我覺得傳入一個內存管理器的方式挺好的啊，比如像nginx這樣的內存管理，有點類似于Apache的apr_pool，但更適合一般的應用，除了性能的提升，更重要的是使用起來更簡單，最終統一釋放，也不容易產生內存泄露。
不懂？學習！
posted on 2012-07-03 21:07? lexus 閱讀( ...) 評論( ...) 編輯 收藏轉載于:https://www.cnblogs.com/lexus/archive/2012/07/03/2575331.html
總結
以上是生活随笔為你收集整理的您知道Linux下C语言编程的一些注意事项吗_教育中国的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java奇谈
- 下一篇： 浏览器访问Linux的Tomcat