在C++/CLI中使用PIMPL慣用語時出現MSVC++鏈接器警告

我正在使用C++/CLI（版本9.0）編寫.NET程序集，並且我想使用PIMPL慣用語以避免將不必要的內容放入公共頭中。不幸的是，當我嘗試着聲明一個類，然後使用一個跟蹤處理它，我得到連接器警告4248：在C++/CLI中使用PIMPL慣用語時出現MSVC++鏈接器警告

警告LNK4248：無法解析typeref令牌（0100000E）爲「MyNamespace.PrivateClass」;圖像可能無法運行

無論我使用CLI類還是本機類作爲實現類，這似乎都是這種情況。

示例代碼如下所示：

namespace MyNamespace 
{ 
    ref class PrivateClass; // forward dec 

    ref class MyPublicClass 
    { 
    private: 
     PrivateClass^ m_Imp; 
    }; 
}

爲警告微軟的解釋是不是太翔實，很遺憾。

來源

2008-12-02 Brian Stewart

我想你使用兩種技術不真正坐在一起好：

自然應用PIMPL是避免使頭文件，從而改變了所有的時間上大C++項目造成很大的重新編譯。

C++/cli的自然應用是編寫簡潔的小互操作代碼片段，並且VS在這些項目上的默認行爲是將所有代碼放入頭文件中，這與您可以獲得的反pimpl大致相同。

如果你寫的東西足夠大以保證pimpl，我不會推薦C++/cli。如果你寫的東西足夠小以使C++/cli合適，我就不會打擾pimpl。

當然情況因人而異，但是這將是我對其採取...

來源

2008-12-04 21:37:20

關於「VS的默認行爲[...]」：我不太明白這一點。程序員必須手動創建`.h`文件和`.cpp`文件（僅包含頭文件的#include），並確保託管類的整個定義進入頭文件。就我所知，VS並沒有自動執行這個約定。 – stakx 2016-05-28 09:54:15

經過進一步的挖掘和反思，我發現.NET在某些方面並不需要像C++一樣支持PIMPL，因爲您可以將一個類標記爲程序集私有 - 這基本上具有相同的效果，在某些方面。然而，PIMPL慣用語通常用於隱藏不希望客戶端編譯的頭文件。但是，當然.NET程序集並不像「C++頭文件」那樣「包含」 - 所以我猜那裏真的沒有問題。

來源

2008-12-04 21:12:19

在C++/CLI中使用PIMPL慣用語時出現MSVC++鏈接器警告

回答

相關問題