1樓：張建濤
windows的堆記憶體管理基於堆控制代碼
crt dll中malloc、free底層均由HeapAlloc、HeapFree實現，每乙個crt dll例項都有自己的預設堆控制代碼叫_crtheap
假設，多個模組均靜態鏈結了crt庫，那就相當於每個模組都在使用自己獨有的_crtheap來HeapAlloc記憶體
把new的指標交給其他模組，其他模組使用錯誤的堆控制代碼_crtheap來delete，當然出問題了
這個問題談不上是問題，知道道理就行了。首先動態鏈結就能避免這個問題，或者自己HeapCreate乙個堆，吧控制代碼傳給其他模組，試試肯定沒問題
另外好多大型工程常常會自行HeapCreate，並自己做記憶體管理，很靈活
這麼設計，除了會讓新手掉個坑以外，好處實在太多，滿足了很多大型工程、效能監控、記憶體追蹤等等等等功能要求
2樓：馮東
請問windows下跨模組釋放是因為dll、exe間全域性變數不自動匯出，從而使執行庫的全域性變數不共享引起的嗎?
並不是因為「變數不匯出」，而是取決於整個程序裡到底有幾份執行庫。如果乙個程序有好幾個 DLL，但是 C runtime library 本身是靜態鏈結。那麼 CRT 就會分別靜態鏈結到每乙個 DLL 以及 exectuable 上，這個每個 DLL 都會有乙個堆。
如果 CRT 是動態鏈結，那麼所有 DLL 本身是不帶 CRT 的，而是都在 runtime 動態鏈結到同乙個 CRT。這樣大家的 malloc/free 對應的都是同乙個堆。
問題答完了，閒扯幾句。
我又特別注意了一下題主說的「只在windows下成立嗎？」。在 Linux 和 macOS 的主要開發工具裡，靜態鏈結 C runtime library 已經不是乙個常見選項了。
我在 Xcode 7.3 裡沒有找到把 CRT 變成靜態鏈結的方法。在 Visual Studio 裡對 CRT 鏈結方式的選擇還是很顯眼的。
這種沒什麼用的選項其實不用暴露在 IDE 中。
引申到軟體的開發方式，現在一般不建議乙個 DLL（或者 macOS 下的 dylib）自己靜態鏈結其它的重量級庫。而是建議把所有大中型的庫都做成動態鏈結。像 macOS / iOS 就把無數的 open source 庫都做成動態鏈結放到系統裡了。
比如 libz 這種東西，macOS / iOS 裡拿來鏈結就行，Windows 裡還要自己 down source 去整合，配不好靜態動態還會出各種問題。
3樓：叛逆者
windows下跨模組釋放是因為dll、exe間全域性變數不自動匯出，從而使執行庫的全域性變數不共享引起的嗎如果你認為是不自動匯出造成的，那麼是不是手動匯出就可以了？試一下就知道，仍然不行。所以就否定了這個假說。
提假說->做實驗->證實或證偽該假說。這是基本的科學方法。
（/MT /MD，這個編譯選項，能不能不要重複重複再重複地出現啊。每過幾天就乙個這樣的問題。）
敏捷開發是不是乙個模組乙個模組的開發
高齡程式設計師 不是，敏捷開發是乙個乙個sprint開發，在短期以內快速迭代，注重溝通弱化文件，每天更新看板和燃盡圖，並且每天一次standing meeting。最後，瞎雞兒搞敏捷的大概率會翻車 今非昨 只是外包軟體公司，在壓榨碼農的道路上乙個折衷方案，說起來高大上，其實深層原因是，沒有乙個好的專...
怎樣成為乙個優秀的模組作者？
桑湛 首先不要搞那種量產套路，咕不是問題，灌水才是。然後一般都是在你日常中突然有了那麼乙個閃光點，你感覺這個很有趣並打算圍繞他展開乙個故事。比如如果是特殊的物品，就有圍繞他轉來的人物與劇情。簡單點可以是兩極類 自己瞎命名 調查員一方與劇情對應一方 我比較喜歡三權分立，或者三權背景調查員作為加入方。圍...
衛星定位問題，能否自製乙個rpk模組？
知乎使用者JksL7y 這個問題很好。現代的rtk定位基礎原理是通過移動站與基準站對同乙個觀測衛星做差分，利用載波相位解算出整週模糊度。您說的是最原始的差分方式。利用單點定位計算出與真實值的誤差，用該誤差做改正。但是有些問題 1 觀測條件是否一致？比如基準站某顆衛星帶來誤差，而移動站該衛星不參與解算...