※ 引述《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