[問題] shared library interface design?

作者: lovejomi (JOMI)   2018-08-22 23:57:34
詢問一個撰寫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一下比較能掌握一些必要觀念
以上幾個問題有點複雜 請教各位
非常感謝
作者: Bencrie   2018-08-23 01:37:00
一個 process 一個 heap。跟 lib 無關
作者: LPH66 (-6.2598534e+18f)   2018-08-23 08:49:00
unique_ptr 可以提供 Deleter 用來釋放所以如果真的要的話其實是可以 (1) library 實做 Deleter或是 (2) 在 Create/Release 的 API 下寫個 Deleter 呼叫
作者: lovejomi (JOMI)   2018-08-23 08:56:00
整體來講是一個heap但是module間heap到底是不是獨立這件事到底誰決定的?
作者: Bencrie   2018-08-23 09:30:00
只有一個 heap 怎麼會有獨立不獨立的問題?
作者: lovejomi (JOMI)   2018-08-23 18:02:00
@lph66: 想一下 如果沒有刻意給deletor他會帶入用default deletor ,這樣不也是讓delete的動作 做在自己身上?所以其實也沒問題 是嗎
作者: AstralBrain   2018-08-23 19:10:00
default_deletor應該會inline展開成delete不會回你的shared lib執行啊.. 只要你的class有實作operator delete就ok可以讓他link到lib裡面的那一份
作者: lovejomi (JOMI)   2018-08-23 22:04:00
這件事也太多眉角了,誰知道到底會不會inline呢@@為什麼說default會被inline, custom的就不會呢?
作者: AstralBrain   2018-08-23 22:45:00
inline有個大前提是要能在compile time看到實作你把實作藏在so裡面他想inline也辦法
作者: cole945 (躂躂..)   2018-08-23 22:57:00
STL本來就是看source code在編的, 不是嗎@@?
作者: saladim (殺拉頂)   2018-09-01 03:16:00
好像函數回傳smart pointer是提示說使用者不用管release的問題 若回傳raw pointer那就有幾種狀況 可能需要搭配lib提供者的release function, 或是實務上也遇過使用者不需要做任何事的設計 得看lib的設計, 至於本篇其他問題還要再研究一下 XD 頭痛

Links booklink

Contact Us: admin [ a t ] ucptt.com