2012-10-05 31 views
0

我正在某些大型庫中添加新模塊。這裏的所有方法都以靜態方式實現。讓我簡要介紹一下簡化模型:在方法中注入附加數據

typedef std::vector<double> TData; 
double test (const TData &arg) { return arg (0) * sin (arg (1) + ...;} 
double (* p_test) (const TData> &arg) = &test; 

class A 
{ 
    public: 
     static T f1 (TData &input) { 
     .... //some computations 
     B::f2 (p_test); 
     } 
}; 

裏面f1()一些計算,執行和靜態方法B::f2被調用。 f2方法由另一個作者實現,並表示一些仿真算法(此處的示例已簡化)。

class B 
{ 
    public: 
     static double f2 (double (* p_test) (const TData &arg)) 
     { 
      //difficult algorithm working p_test many times 
      double res = p_test(arg); 
     } 
}; 

f2方法有一個指針指向一些權重函數(這裏p_test)。但在我的情況下f1test()方法計算一些額外的參數需要

double test (const TData &arg, const TData &arg2, char *arg3....) { } 

如何將這些參數注入test()(依此來f2),以避免改變的f2方法的源代碼(即不平凡),重新設計圖書館並且沒有骯髒的黑客:-)?

最簡單的步驟是覆蓋f2

static double f2 (double (* p_test) (const TData &arg), const TData &arg2, char *arg3.... ) 

但是以後怎麼辦?考慮一下,這些方法是靜態的,所以對象會有問題。


更新問題

是否有可能使一個指針的函數依賴於一些模板參數或做類似的東西

if (condition) res = p_test(arg); 
else res = p_test2(arg, arg2, arg3); 

回答

0

「避免改變」,那麼這是一個有點困難。但是,您可以使用靜態變量將參數傳遞給不傳遞參數的函數調用。

請記住,如果有多個線程使用這些函數,則需要使用線程本地存儲(這是我推薦的方式),或者確保正確的相互排斥使用這些變量,在這種情況下在所有線程之間共享的單個變量的含義意味着一直排除在調用鏈之外。但如果線程是一個問題,請使用線程本地存儲。如果沒有線程問題,那麼沒問題! :-)

0

不髒黑客

不會發生的。如果你不能修改採用函數指針的函數的源代碼,你將不得不使用異常嘔吐來獲得額外的參數。如果您有支持thread_local的C++ 11編譯器(尚不存在),理論上可以做更好的事情,或者可以使用特定於操作系統的TLS。但就目前而言,唯一的便攜式解決方案就是一種例外嘔吐物。

void f(void(*fp)()) { fp(); } 
void mah_func() { 
    try { 
     throw; 
    } catch(my_class* m) { 
     m->func(); 
    } 
} 
int main() { 
    my_class m; 
    try { 
     throw &m; 
    } catch(my_class* p) { 
     f(mah_func); 
    } 
} 

或者,在你的情況下,修改f2似乎沒有是不可能的,唯一的困難。然而,改變它以採取std::function<double(const TData&)>的難度會很低,所有你需要做的就是改變參數類型,這要歸功於運算符的重載。對於一個複雜的函數,它應該是一個非常簡單的改變,因爲你只是改變函數參數的類型,所有的調用站點仍然可以工作,等等。然後你可以傳遞一個合適的函數對象,通過bind或lambda或者其他。

+0

@ DeadMG:謝謝,它看起來像一個有趣的想法...... – justik

+0

如果編譯器支持線程安全的異常,那麼很可能它也支持。提升線程。所以,清理者可以直接使用線程本地存儲。如果編譯器不支持線程安全異常(並且C++ 03標準支持線程中沒有任何內容),那麼這種技術雖然在技術上很有趣,但不是可移植的*。 –

+0

@乾杯和hth。 - Alf謝謝你的重要評論。 – justik

相關問題