補充一些 PkmX 沒提到的東西和補一個簡單點的例子 ※ 引述《dreamboat66 (小嫩)》之銘言： : 假設我expose某函數void * GetInstance(int version); : 我可能會回傳兩種type, Type1 or Type2 : 使用者就要用 : auto inst = reinterpret_cast<Type1* or Type2>(GetInstance(version)); 而因為 C/C++ 無法在 runtime 知道 type 的細節 (reflection), 所以一般會約定好一致的介面 (API), 遵循一個 main program 已知的介面 來實作, 例如 class TypeCommon { public: virtual do_something(); virtual do_anotherthing(); }; class Type1: public TypeCommon { .. } class Type2: public TypeCommon { .. } TypeCommon *GetInstance(int version); 你這裡的盲點是, 主程式根本不需要知道 Type1, Type2, 想像一下 Firefox 外掛誰都可以寫, 而 Firefox 根本不需要知道那些外掛的存在 而主程式只要知道 TypeCommon 的樣子, dynamic load 來的 Type1, Type2 不過都是 當作 TypeCommon 在操作, 說穿了就只是基本的 interface/implemation 概念 : 之後就可以呼叫inst->Func1(); : 說到這邊我不了解的事情是 : 使用者並沒有.so or .lib : 我的這class Type1 在header裡面是不是要按照某一種規範來實作才能做到 對 : 不需要.so or .lib就能夠編譯自己的執行檔出來 基本上這是 linking 的事, 沒有指名道性要用到, linking 時就不需要 : class Type1{ : public: : 1. 是不是讓Type1整個class都只有pure virtual function即可 : virtual void Func() = 0; 如果你明白了主程式不需要知道 Type1 這件事, 其實 Type1 有沒有 pure 不重要. 新的問題是, 橋接 主程式和外掛的 TypeCommon 是不是要 pure? 答案是都可以, 但 link 時會有點差, 主要是 member 會被主程式和外掛都用到, 那應該由誰來提供的問題 : 2. 是不是有了非pure的virtual function, 編譯的時候就會需要.so or .lib來做link？ : virtual void Func(); 不是. 會不會用到是看程式有沒有直接用到 Type1, Type2 : 3. 同上 : void Func(); ? : 4. 如果class內有member的話,是不是也要看這member的型態是不是也滿足 : 這邊要問的條件? : }; : 5. 還是說根本不是class 本身的問題而是要透過一些compiler關鍵字來做到？ : dllexport or __attribute之類的？ : 我自己因為只有微薄的windows開發經驗 印象中都需要提供.lib給使用者做link : 但又看到某些產品是可做到需要用到某功能的時候 : 才去server runtime download動態lib下來執行 : 這樣為什麼他在編譯自己執行檔時可以不需要.so or .lib一起做編譯呢？ : 也不會遇到unresolved external symbol之類找不到定義的問題呢？ : 謝謝 先舉一個不是 dynamic load 的例子, 然後我們再把他轉成 dlopen 的用法 // plugin.h 提供共同介面 #ifndef __PLUGIN_H #define __PLUGIN_H class plugin { public: virtual int getNum() = 0; int sum(); virtual ~plugin(); }; #endif // plugin.cc // 這個 plugin 很簡單, sum() 回傳 123 + 某個值, // 而每個實作這個 plugin 的人自行定義 getNum() #include "plugin.h" int plugin::sum() { return 123 + getNum(); } plugin::~plugin() {} // foo.cc // foo plugin 實作 getNum 為 111 #include "plugin.h" #include <iostream> class foo: public plugin { public: int getNum() override { return 111; } virtual ~foo() { std::cout << "foo deleted" << std::endl; } }; extern "C" plugin* new_foo() { // 提供一個 new foo 的方法 return new foo(); } // bar.cc // 同理你可以實作一個 bar, 實作不同的 getNum, 例如 222 // main.cc #include "plugin.h" #include <iostream> #include <dlfcn.h> extern "C" plugin* new_bar(); extern "C" plugin* new_foo(); int main () { // 從 main 的觀點, 不需要知道 foo 和 bar plugin *f = new_foo(); plugin *b = new_bar(); // 只要認得 plugin::getNum 和 plugin::sum 就好了 std::cout << f->getNum() << ", " << f->sum() << std::endl; // 111 234 std::cout << b->getNum() << ", " << b->sum() << std::endl; // 222 345 delete f; // foo delete delete b; // bar delete g++ -std=c++11 -pedantic \ main.cc plugin.cc foo.cc bar.cc -ldl - - - - - - - 以上就只是單的 C++ code, 應該大致可以理解? 如果是使用 dlopen 呢? 對主程式而言, 一般不會直接使用 new_foo, new_bar, 若每個 plugin 都有自已的 new function, 主程式還要先知道 new function 的名程, 所以可以定一個同名的 new function. 不同的 plugin (.so) 是不同的 link module, 不會有 multiple define 的問題. // in foo.cc/bar.cc extern "C" plugin* new_object() { // 提供一個 new foo 的方法 return new foo(); } 或是 foo.c 如果不限於在 dlopen 時動態載入, 也可以保留原本的 make_foo 再另外定一個 weak alias new_object 給 dlsym 時使用 extern "C" plugin* new_object () __attribute__((weak, alias("new_foo"))); // in main.cc // 用於 new_object 的 function pointer type extern "C" typedef plugin* (*new_fp)(); plugin *f, *b; // 分別開啟 libfoo, libbar 的 handle auto fh = dlopen("./libfoo.so", RTLD_LAZY); auto bh = dlopen("./libbar.so", RTLD_LAZY); // 固定使用 new_object 找出兩個 plugin 的 new function auto make_foo_fp = (new_fp) dlsym(fh, "new_object"); auto make_bar_fp = (new_fp) dlsym(fh, "new_object"); // 以下的用法其實就與原本大同小異了 f = make_foo_fp(); b = make_bar_fp(); std::cout << f->getNum() << ", " << f->sum() << std::endl; std::cout << b->getNum() << ", " << b->sum() << std::endl; delete f; delete b; - - - - # 若使用我上提供到的 weak alias 的做法, # foo/bar 可以直接與 main link 起來直接使用, # 也可以編成 shard object 透過 dlopen/dlsym 使用 CFLAGS="-std=c++11 -pedantic -g" g++ ${CFLAGS} -fpic -shared foo.cc plugin.cc -o libfoo.so g++ ${CFLAGS} -fpic -shared bar.cc plugin.cc -o libbar.so g++ ${CFLAGS} plugin.cc main.cc foo.cc bar.cc -ldl - - 這邊有另一個細節上面沒有提到. 因為 plugin class 有部份實作, 或本身的 type_info 這個實作應該由誰提供? 例如 foo class 本如果要乎叫 plugin::sum, 那這份 code 應該是主程式 a.out 還是 libfoo.so 提供? 以我上面的子, 其實 main, foo, bar 都會有一份 plugin class 的實作, 這些會有額外不必要的重覆. 而若 plugin class 本身 link 進 foo/bar, 會造成維護上的問題, 例如新版程式的 plugin class 改版. 為了避開這問題大至有兩種做法. 一) 改成由 main 主程式提供實作 CFLAGS="-std=c++11 -pedantic -g" g++ ${CFLAGS} -fpic -shared foo.cc -o libfoo.so g++ ${CFLAGS} -fpic -shared bar.cc -o libbar.so g++ ${CFLAGS} -rdynamnic plugin.cc main.cc foo.cc bar.cc -ldl 一般在 link 時, 若主式的 function 沒有被其他 shared object 使用到, 就不會 export 到 dynamic symbol 中, 若沒有被 export 到 dynamic table, 那這個 symbol 就不會被用來解析 dynamic loading. 例如 // foo.c void test(); void foo() { test(); } // main.c void test() {...} void foo(); int main () { foo (); } void bar() {... } $ gcc foo.c -fpic -shared -o libfoo.so $ gcc main.c -L. -lfoo 這就與 link static library (.a) 時的狀況一樣, 有可能 libfoo.so 本身不提供 test(), 而是其他 lib, 甚至 main 本身 提供 test() function. 差別只是 test() 會被 export 到 dynamic symbol table 供載入 libfoo.so 時使用. 但使用 dlopen 時, linker 並不會發生有人要使用 test() function. 所以 -rdynamic 在這的用途是告訴 linker, 有看不到的 user 會使用不知道哪個 sybmol, 把所有 symbol 都 export 出去. 不過這樣其實就太過頭了, 會有不必要的的 symbol 汙染. 而且大型專案 symbol 常常會數以萬計. 所以另一個做法其實就只是把 plugin 本身也變成 libray讓 main, foo,bar 供用 g++ ${CFLAGS} -fpic -shared plugin.cc -o libplugin.so g++ ${CFLAGS} -fpic -shared foo.cc -L. -lplugin -o libfoo.so g++ ${CFLAGS} -fpic -shared bar.cc -L. -lplugin -o libbar.so g++ ${CFLAGS} main.cc -L. -lplugin -ldl --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.204.230 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1507399596.A.A13.html