[問題] shared library interface design?

看板C_and_CPP作者 (JOMI)時間7年前 (2018/08/22 23:57), 7年前編輯推噓7(7推 0噓 17→)
留言24則, 6人參與, 7年前最新討論串1/3 (看更多)
詢問一個撰寫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
推
08/23 01:37, 7年前 , 1F
一個 process 一個 heap。跟 lib 無關
08/23 01:37, 1F
推
08/23 08:49, 7年前 , 2F
unique_ptr 可以提供 Deleter 用來釋放
08/23 08:49, 2F
→
08/23 08:50, 7年前 , 3F
所以如果真的要的話其實是可以 (1) library 實做 Deleter
08/23 08:50, 3F
→
08/23 08:50, 7年前 , 4F
或是 (2) 在 Create/Release 的 API 下寫個 Deleter 呼叫
08/23 08:50, 4F
→
08/23 08:56, 7年前 , 5F
整體來講是一個heap但是module間heap到底是不是獨立這
08/23 08:56, 5F
→
08/23 08:56, 7年前 , 6F
件事到底誰決定的？
08/23 08:56, 6F
推
08/23 09:30, 7年前 , 7F
只有一個 heap 怎麼會有獨立不獨立的問題？
08/23 09:30, 7F
→
08/23 18:02, 7年前 , 8F
@lph66: 想一下 如果沒有刻意給deletor他會帶入用defaul
08/23 18:02, 8F
→
08/23 18:02, 7年前 , 9F
t deletor ，這樣不也是讓delete的動作 做在自己身上？
08/23 18:02, 9F
→
08/23 18:02, 7年前 , 10F
所以其實也沒問題 是嗎
08/23 18:02, 10F
推
08/23 19:10, 7年前 , 11F
default_deletor應該會inline展開成delete
08/23 19:10, 11F
→
08/23 19:10, 7年前 , 12F
不會回你的shared lib執行
08/23 19:10, 12F
推
08/23 20:54, 7年前 , 13F
啊.. 只要你的class有實作operator delete就ok
08/23 20:54, 13F
→
08/23 20:54, 7年前 , 14F
可以讓他link到lib裡面的那一份
08/23 20:54, 14F
→
08/23 22:04, 7年前 , 15F
這件事也太多眉角了，誰知道到底會不會inline呢@@
08/23 22:04, 15F
→
08/23 22:17, 7年前 , 16F
為什麼說default會被inline, custom的就不會呢？
08/23 22:17, 16F
推
08/23 22:45, 7年前 , 17F
inline有個大前提是要能在compile time看到實作
08/23 22:45, 17F
→
08/23 22:46, 7年前 , 18F
你把實作藏在so裡面他想inline也辦法
08/23 22:46, 18F
推
08/23 22:57, 7年前 , 19F
STL本來就是看source code在編的, 不是嗎@@?
08/23 22:57, 19F
→
09/01 03:16, 7年前 , 20F
好像函數回傳smart pointer是提示說使用者不用管release
09/01 03:16, 20F
→
09/01 03:16, 7年前 , 21F
的問題 若回傳raw pointer那就有幾種狀況 可能需要搭配
09/01 03:16, 21F
→
09/01 03:18, 7年前 , 22F
lib提供者的release function, 或是實務上也遇過使用者
09/01 03:18, 22F
→
09/01 03:18, 7年前 , 23F
不需要做任何事的設計 得看lib的設計, 至於本篇其他問題
09/01 03:18, 23F
→
09/01 03:19, 7年前 , 24F
還要再研究一下 XD 頭痛
09/01 03:19, 24F
‣ 更多 lovejomi 的文章
文章代碼(AID): #1RVOVm3N (C_and_CPP)
‣ 更多 lovejomi 的文章
文章代碼(AID): #1RVOVm3N (C_and_CPP)