※ 引述《sunneo (艾斯寇德)》之銘言： : 這裡是指其他的process沒錯 : 不過這裡是舉單純是對無效位址free的例子 : 假使有一以shared共享的全域變數個指標使用malloc配置記憶體並且作為回傳值 : 這時候別的process看到的可能是同一個記憶體位址，因為是一個共享變數的資料 : 但該位址在自己的proecss不見得有配置記憶體，那麼再free的時候就會失敗。 : 這裡說的shared修飾是以下這兩種 : #pragma data_seg("shared") : __attribute__((section ("Shared"), shared)) : (或者單純只是在win 95/98/me下的情形) 我想你說的沒錯，但老實這個情況有點極端，因為在 shared section 放 pointer 的唯一用處，就是這個 pointer 指向同在 shared section 的記 憶體區塊。拿來指向 malloc 的結果，對其它 process 來說完全無用，我 好奇哪個人會這樣寫 DLL。 回到原po的問題，在 DLL 中呼叫 malloc 而在 client code 呼叫 free， 我認為並沒有什麼技術上的問題，但在 library 的設計上這樣做的確是不 好的。比如說你寫了某個 function 會回傳 malloc 配置到的空間： int* foo(void) { int* p = malloc(...); ... // 一些運算 return p; } 乍看之下，只要呼叫 foo() 的那端有確實呼叫 free 來釋放記憶體，就不 會有 memory leak 的問題。但要是過了一陣子，你想把 malloc 改成new (或是你想自己寫 memory allocator)，問題就來了。因為用 new 去配置 的區塊必需用 delete 去釋放，所以你這一改，所有呼叫到 foo() 的地方 也都要跟著改了。 改進方法是寫另一個 function 去釋放記憶體： void Release(int* p) { // client code 一定要呼叫 Release 才能釋放記憶體 // 所以要是我們改用 new 來配置，只要在這邊改成 // delete 即可 free(p); } 設計上有個要點是：當你寫了某個會配置資源並回傳給 client 的 function， 那你應該也要寫一個對應的 function 來釋放資源。這麼一來，client 就完 全不需要知道你如何配置及釋放，你隨時可以抽換這部份的功能。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.121.114.95