Re: [問題] delete / new , free / malloc

看板C_and_CPP作者tinlans ( )時間12年前 (2012/01/14 01:50)推噓19(19推 0噓 7→)

留言26則, 21人參與討論串7/7 (看更多)

※ 引述《QQ29 (我愛阿蓉)》之銘言： : new / delete vs malloc / free : 請教各位一個小問題 : 我看msdn的一個sample code : http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917(v=vs.85).aspx : 這底下有一個sample : 有這行 : pAdapterInfo = (IP_ADAPTER_INFO *) MALLOC(ulOutBufLen); : 他使用了malloc : 但聽說能用new / delete 就盡量用完全沒有這種事... 書上只會告訴你 new 要搭 delete，new[] 要搭 delete[]，malloc() 要搭 free()。你不可以混著搭。就這樣，沒有別的了。至於該用 new 還是 malloc()，一切都是看你需求，看你高興。 C++ 之所以要設計這個 new/delete，只是為了： 1. 增加程式開發的效率。 2. 減少手寫碼，由編譯器來產生在 C 需要重複撰寫的部分，有效減少人為錯誤。但如果今天你要配置的東西，並不需要固定的 initialize 和 finalize 步驟，那你沒事去用什麼 new/delete 幹嘛？語言機制是因使用需求而誕生。你有需求就去用，沒需求就不必用。 : 所以 : 我想使用new 這operator來做 : 但有個疑問 : ulOutBufLen 這個值有可能 "大於" sizeof(IP_ADAPTER_INFO). : 假如我用 : pAdapterInfo = (IP_ADAPTER_INFO *) new char[ulOutBufLen]; : 這樣安全嗎 ....................... 在思考安不安全之前，你應該先思考為什麼你要這樣寫。坦白說，因為你用了 C++ 的 new，我卻又看見 C-style cast，這令我感到十分不安。但這完全不是重點，只是另一個層次的個人堅持，所以先放一邊。今天如果這東西是設計成讓你用 new，那 code 應該寫成： pAdapterInfo = new IP_ADAPTER_INFO; 或 pAdapterInfo = new IP_ADAPTER_INFO(/* argument list */); 譬如： pAdapterInfo = new IP_ADAPTER_INFO(ulOutBufLen); 這樣才叫做 C++，才是 C++ 的 library/framework 的 design concept。但現在很顯然就不是這樣，那你就不應該堅持使用 new。這個基本的 sense 一定要培養起來，不然將來拿 C++ 去寫跟底層接合的東西會很混亂。你必須一眼就能發現這東西根本就是 C code 或 C API，然後毫無疑惑地捨棄 new。還有他用的是 MALLOC()，不是 malloc()，你根本不應該預期你可以換成 new。天知道這個 MALLOC() 在編譯器下了不同選項後是否能產生其它效果。你一旦把它置換成 new，你就等於是破壞了這一切的彈性。我不熟你使用的平台。但如果是我特別設計了一個 MALLOC() 給人用... 首先全部大寫這應該會是一個 macro。然後我可能會在 debug mode on 的時候，替它增加一些神奇的統計和除錯功能。但是你今天卻辜負了我這個心意，去把它當成 malloc() 看待，還改寫成 new，那麼我一定會非常震怒，把你罵得無地自容。不過它 example 既然寫了那段註解，我想原作者也默許你改用 malloc() 了吧。 : 如果沒問題的話 : 我使用 : delete pAdapterInfo; 就能把這一串連續空間標記起來嗎? : 我是不曉得他delete怎麼去判定你的 new/delete 搭配不成對。這個別人講過了我就不多說。 : 他連續空間哪一段是他配置的 : 我很怕 : delete pAdapterInfo; 只是把sizeof(IP_ADAPTER_INFO)byte的記憶體給標記因為你用的是 delete，所以你害怕的事情確實會發生。 : 而實際上 : 我是需要delete 掉sizeof(IP_ADAPTER_INFO) bytes的資訊. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 你的 ulOutBufLen 去哪了？ : 相較於delete / new : malloc / free 是不是就沒這問題了? 這兩種東西的用途不同，需求也不一樣。在這個場合，你不應該使用 new/delete，而不是把它們放在一起比較誰有沒有這問題。光看最後幾句話，連外行人都覺得是對的。但打個簡單的比喻... 就像小學生在作答計算題，他因為某個機緣知道這答案是 12，然而他不知道該怎麼算出 12。於是他湊了一大堆亂七八糟的算式，最後突然寫個 = 12。你是閱卷老師的話，你應該要跟這名學生說 = 12 對或錯，還是跟他說過程哪裡不對？所以這邊我不回答你這個和上述「= 12」一樣的設問結論，希望你能理解。 : free(pAdapterInfo) 他就是會從這個起始位址 free到他剛剛配置的空間的結尾. : 因為我看他範例就直接free了... 因為我沒來這板很久了，對板友的現況已經是狀況外，不確定你資料結構和 OS 上了沒。上過的話，記憶體管理的章節可以去複習一下，上面有講記憶體管理的原理。「會從這個起始位址 free 到他剛剛配置的空間的結尾」這種說法完全沒有 sense。 free 記憶體的概念沒有所謂的 from ... to ... 這種說法。你這樣說就好像它是一個 byte 一個 byte 慢慢去清理的，這樣不好。配置記憶體時，基本上就會記錄配給你的位址，跟你當初要的長度。當你釋放的時候，只要給它位址，它自然就能把當初配置給你的空間回收。所以你只能說「把當初配走的記憶體空間 release」，沒有從哪 free 到哪這種說法。 new[]/delete[] 的行為是經過高階包裝過的，那根本是另一回事。但我認為在這裡繼續扯進細節對你是百害而無一利，所以就此打住。 : ps.請問有沒有什麼方式可以驗證我確實delete 標記掉了多少byte嗎? 承上，「delete 標記掉了多少byte」這說法也是完全沒有 sense。沒有這種講法。坦白說，這很像我英文補習班的老外用奇怪的中文跟我講話一樣... 你給我的感覺很像 C/C++ 語言圈的歪果仁。我對他唯一不滿的地方，就是每次我講了文法對但沒人這樣講的英文時，他都不會糾正。一定要我看著同學狐疑的表情，我去問他，他才會告訴我一般人都怎樣講。因為我實在不喜歡那樣，所以我也不是故意去挑你毛病找你麻煩，只是做我覺得對的事。本來看很多人回了就沒打算回，加上真的很忙。但整篇看下來全身都覺得不舒服，想想還是回一下比較好。 : 因為我也不知道我自己這樣寫有沒有問題~~ 謝謝 : 謝謝 win 平台的驗證方式不是我能回答的，所以略過。整篇看下來... 你的問題在於還沒以抽象的概念建立正確的觀念和認知，就開始執著於瞭解底層實作。我在接觸 OS / VM / compiler 的 source code 前，你會想的這些問題我都是不管的。因為以往從書上建立起的抽象概念就是這邊本來就會這樣，應該要這樣，當然要這樣。學數學也是這樣啊，你起碼要先會用定理，再去證明這些定理為什麼會對。你連定理本身的特性都還沒摸清楚，總是把它用在不對的地方，那你先去證它幹嘛。搞不好因為你對定理的誤解，證明的方向打從一開始就完全錯了，徒然浪費時間。生活在現代，前人累積下來的知識可以讓你少走很多冤枉路。特別是程式語言是有限的語言，它可以 100% 確定 always true 的特性多到不行。能 100% 確定的東西都不先吸收起來，去接觸那些模稜兩可的東西只會讓你更頭大。只能說書真的要多看，而且要認真看，也不能照台灣失敗教育那一套速食主義來唸書。雖然前面的人都建議你去看實作怎麼玩，但我的立場還是建議你還是多看書。多看 code 就能把程式寫得好，多 trace code 就能明白程式怎麼運作等等... 20 年前我是贊同的，因為時空背景不一樣，當時程式也簡單，規模又小，語言不複雜。現在到處都是高階語言，到處都是人家系統化整理過的書，你先多看書就好。當然因為現在 80 年代的 code 依然在世上四處流竄，你總有一天還是得去多看 code。但我只能說，絕對不是現在，這個時機太差了。想想等你靠著看 code 摸透一切，你都幾歲了，競爭力剩下多少？很多老師喜歡裝開明、裝先進。盲目告訴你不要盡信書本的知識，書上寫的不一定是對的... 但這說法真的害死了很多人，因為有很多該列入考慮的東西都沒提到。只是像隻鸚鵡一樣 repeat 那幾句名言，根本就是誤人子弟。很多時候，特別是在建立基礎的時候，你讀三頁書勝過你 trace 千行 code。夜深了不說下去了，禮拜天還要繼續上托福寫作課，先去唸書。 -- Ling-hua Tseng (uranus@tinlans.org) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: http://www.tinlans.org -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.114.36 ※ 編輯: tinlans 來自: 118.160.114.36 (01/14 01:59)

推

VictorTom

01/14 02:27, , 1^F

01/14 02:27, 1^F

→

VictorTom

01/14 02:29, , 2^F

01/14 02:29, 2^F

→

VictorTom

01/14 02:29, , 3^F

01/14 02:29, 3^F