[問題] shared library interface design?

[lovejomi (JOMI)]

詢問一個撰寫c++ shared library (.so) 給 client使用的問題

看到一份code, .so 的header 提供的api prototype是長這樣

std::unique_ptr<Foo> CreateFoo();

這很明顯的是

allocate的動作在lib裡面

deallocate的人一定在caller那端也就是client code

a. 這是不是一個很不正確的design?

基於一個觀念

不該把new跟delete的動作, 在不同library間執行
之前觀念是因為heap是獨立的, 所以會出問題
b. 但這觀念是不是只有windows上才有呢? 不確定
以下連結也只提到dll

https://stackoverflow.com/questions/443147/c-mix-new-delete-between-libs

針對這件事 我並沒有明確的google到有什麼guideline提到該怎麼設計

如果是以我經驗來說

多半是

Foo* Create() 搭配 void Release(Foo*)

但這感覺比較偏向C, 而這樣好像也限制client端得到這個Foo*後無法用smart pointer去
hold.

所以以我的想法會覺得

回傳

weak_ptr<Foo> or shared_ptr<Foo> Create(); 給client

然後Create函數裡面實作的時候使用一個global之類的container,
把這sp記錄起來確保 .so是最後一個去delete他的人

但這邊衍伸一個疑問

c. a.exe + b.so 使用load time dynamic link的話,
   a.exe還是b.so的global變數會先開始解構?

如果是使用 run time dynamic link的話

d. 如果client用dlopen 然後dlsym拿到一個sp後
   手動呼叫dlclose....這時候繼續使用這個sp 是不是會有undefined的行為產生?
   就算沒有人解構可是.so已經被close了?

e. 不能在不同的library間 new delete這件事 是否是platform/compiler dependent?
   假設linux上如果我測試發現沒有出問題 是否表示在這compiler/platform下
   100%不會發生問題
   還是說"有可能" 不定時的出現問題 而不能馬上當下發現立刻修正?
   因為目前使用那個shared library(return unique ptr)並沒發生問題
   會不會之後在某特定情況下突然出現問題呢?
   會有 lib 間 heap是獨立的這件事 是gcc / vc實作決定的嗎 還是更底層 OS實作?

f. 以我的觀念來看 如果是.a 的static lib, 是不是就完全沒有design上特別的考量
   不需要特別去因為寫static library而有特別需要注意的地方?

g. 如果一個exe使用多個.so 而這些.so都用不同版本的gcc build出來的
   這樣如果他們expose的api 含有 stl的type
   是不是就是一個非常不好的design?
   如果我真的要使用這些不同版本的.so 是不是只能祈禱不會出事情而無法作解決?
   而這問題是不是只要這些.so用dynamic link libstdc++就沒事了?


h. 有沒有什麼網頁有特別針對shared library的interface design 有提供guideline?
   想要稍微go through一下比較能掌握一些必要觀念


以上幾個問題有點複雜 請教各位

非常感謝

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 39.10.166.239
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1534953456.A.0D7.html
※ 編輯: lovejomi (39.10.166.239), 08/23/2018 00:08:54
※ 編輯: lovejomi (39.10.166.239), 08/23/2018 00:12:38
※ 編輯: lovejomi (39.10.166.239), 08/23/2018 00:27:33
推 Bencrie: 一個 process 一個 heap。跟 lib 無關
推 LPH66: unique_ptr 可以提供 Deleter 用來釋放
→ LPH66: 所以如果真的要的話其實是可以 (1) library 實做 Deleter
→ LPH66: 或是 (2) 在 Create/Release 的 API 下寫個 Deleter 呼叫
→ lovejomi: 整體來講是一個heap但是module間heap到底是不是獨立這
→ lovejomi: 件事到底誰決定的？
推 Bencrie: 只有一個 heap 怎麼會有獨立不獨立的問題？
→ lovejomi: @lph66: 想一下 如果沒有刻意給deletor他會帶入用defaul
→ lovejomi: t deletor ，這樣不也是讓delete的動作 做在自己身上？
→ lovejomi: 所以其實也沒問題 是嗎
推 AstralBrain: default_deletor應該會inline展開成delete
→ AstralBrain: 不會回你的shared lib執行
推 AstralBrain: 啊.. 只要你的class有實作operator delete就ok
→ AstralBrain: 可以讓他link到lib裡面的那一份
→ lovejomi: 這件事也太多眉角了，誰知道到底會不會inline呢@@
→ lovejomi: 為什麼說default會被inline, custom的就不會呢？
推 AstralBrain: inline有個大前提是要能在compile time看到實作
→ AstralBrain: 你把實作藏在so裡面他想inline也辦法
推 cole945: STL本來就是看source code在編的, 不是嗎@@?
→ saladim: 好像函數回傳smart pointer是提示說使用者不用管release
→ saladim: 的問題  若回傳raw pointer那就有幾種狀況 可能需要搭配
→ saladim: lib提供者的release function, 或是實務上也遇過使用者
→ saladim: 不需要做任何事的設計 得看lib的設計, 至於本篇其他問題
→ saladim: 還要再研究一下 XD 頭痛