創建一個通用包裝器，該包裝器返回std :: mem_fn或boost :: mem_fn

Question

KDE / PIM Zanshin項目在其整個代碼中的許多位置都使用std :: mem_fn，事實證明，至少有1個版本的Apple clang（該版本隨附了可用於OS X 10.9的最新Xcode）。無法鏈接涉及的許多文件。

事實證明，可以通過使用boost::mem_fn而不是std::mem_fn來解決此問題。 該項目的主要作者並不傾向於增加所有平台上的boost依賴性，因此我提出了一個補丁，其中使用了條件宏，該宏在需要時擴展為boost::mem_fn 。

現在的請求是創建一個模板函數，該函數駐留在zanshin自己的名稱空間之一（ Utils::mem_fn(f) ）中，並返回std::mem_fn(f)或boost::mem_fn(f) 。 那是比我目前的薪水高得多的部分……或者這是不可行的，這與我什至不了解mem_fn函數的目的這一事實無關。

所以問題是：有沒有一種簡便 ，緊湊的方法來包裝std::mem_fn ，理想情況下是使用單個模板函數包裝？

主要障礙似乎是返回類型，但是由於zanshin代碼中的所有用法似乎都將返回的內容歸結為函數指針，因此我嘗試使用void*返回類型。 我以為那會失敗，的確如此。

Answer 1

“項目的主要作者並不傾向於增加對所有平台的增強依賴性”

因此，相反，他給項目帶來了不一致的依賴關系？ 聲音歪了。

而且，它根本不是平台特定的依賴項，因為您可以簡單地在代碼庫中包含相關的標頭（另請參見BCP），並且首先沒有相關的運行時依賴項。

就是說，更簡單的選擇是擁有一個包裝std::mem_fn的包裝器，並在相同的練習（引用的成員的地址）上進行包裝。 這樣，鏈接問題實際上應該消失了。

最簡單的事情是（c ++ 14）：

template <typename PTMorPTMF>
    auto my_mem_fn(PTMorPTMF const& ptm) { 
        return std::mem_fn(ptm);
    }

如果您堅持使用c ++ 11：

template <typename PTMorPTMF>
    auto my_mem_fn(PTMorPTMF const& ptm) -> decltype(std::mem_fn(ptm)) { 
        return std::mem_fn(ptm);
   }

簡單地#ifdef實現，如果您最終只能通過一個平台的增強實現它。