2015-05-15 37 views
2

我試圖找到不同的方法來在不同的應用程序中重用我的C++函數。舉例來說,我有以下功能:尋找不同的方法來與不同的C++應用程序共享C++函數

 Function A(){} // this will do a complex math operation 

     Function B(){} // this will load a complex shape file 

     Function C(){} // Print the results. 

我需要在3個不同的C++程序中使用上述3個函數。它們是完全獨立的,我試圖看看在我的所有應用程序中使用它們的最佳方式,而不是三次寫入相同的代碼。

我想到了以下選項:

 Option A: Writing static library 
     Option B: Writing dynamic library 
     Option C: Windows Services 
     Option D: Same code and compile everywhere 

是否還有其他選擇嗎?或者什麼是最好的選擇?

+3

唯一可能的答案可能是:這取決於!它依賴的東西很多,首先取決於你的用例,這對我們來說是未知的。這也取決於你是否希望「功能」是類似於實用程序的功能,如果你能預測它們將來的所有用途(通常你不能這樣做),如果未知的應用程序要使用這些功能,以及未來的未知用途應用程序可能想要使用你的函數,允許函數被遠程「調用」(即通過網絡),還有很多其他的東西。所以不幸的是你的問題是目前廣泛的 –

+0

[未來](http://clang.llvm.org/docs/Modules.html) –

+0

只要做一個靜態庫,然後如果你需要,你可以把它變成一個稍後動態庫。由於Window Service通常提供完整的服務而不僅僅是一項功能,而且您必須具有某種進程間接口,例如管道,共享內存,共享數據文件或插座。 –

回答

1

如果這些功能只會被您和/或您的同事稱爲「內部」(即他們不會接觸到無法訪問您的源代碼庫的人員)則選項(D)就足夠了。只需將.cpp和.h文件保存在源代碼庫的一個衆所周知的子目錄中,並讓每個應用程序的項目文件根據需要引用它們。這很容易實現,並給你最大的靈活性(因爲每個項目都可以編譯帶有不同編譯器標誌的共享.cpp文件,這些編譯器標誌最適合自己的需要,如果有必要的話) - 一個庫,你必須找出一套的編譯器標誌適用於所有希望鏈接到庫的應用程序,但這並不總是方便的)。

如果你正在編寫用於公共消費的一個API,OTOH,事情變得更加複雜,因爲你發佈的代碼給公衆後,你將不再是完全控制這些都是習慣的版本和位置。在這種情況下,您將不得不根據您的用戶以及您認爲他們最適合的方式做出決定。

可能會拋出選項C,因爲這對於這類事情來說是過度的,並且會帶來將代碼綁定到特定操作系統而不具有補償優勢的懲罰。

1

它是選項D(無處不在編譯) - 唯一的例外是與許多其他人(或封閉源)共享的獨立庫。

  • 這使管理髮布變得容易很多,因爲實際上沒有任何 - 每個副本都可以獨立更新 - 只要方便。
  • 這使得使用正在使用的庫的特定版本,可以輕鬆地將每個項目調試到庫中。
  • 這使您可以選擇爲每個項目定製庫 - 但明智地使用此功能可最大限度地降低合併複雜性。

這個選擇與您是否將它構建到單獨的二進制包中作爲構建過程的一部分無關。

我會推薦使用像git-submodules來管理代碼 - 除了the git-submodules feature is kind of half-baked

相關問題