2 
c:\program files\microsoft visual studio 9.0\vc\include\result.h(212) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>'
1>        with
1>        [
1>            _Alloc=std::allocator<mysqlpp::Row>
1>        ]
1>        C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux'

これはコンテナーに関連する問題の原因になる可能性がありますか?それとも、Visual Studio 2008 で安全に無視できますか?

4

1 に答える 1

2

この場合、std::runtime_error に依存すると思います。クライアントがこのクラスを使用するには、DLL 側ではなく、クライアント側で提供される定義を使用する必要があります。これを成功させるには、クライアント コンパイラが DLL コンパイラとまったく同じバージョンである必要があります。

また、クラス定義がモジュールの境界を越えて移植できないという事実とは別に、考慮すべきメモリの所有権もあります。

std::string のような内部変数を持つクラスから派生した場合、それは起こるのを待っている災害になります。dll が、別のクラスが派生するアプリケーションとは異なるランタイムを使用する場合、次のことが発生する可能性があります。

  • Base は、文字列をテキスト値で初期化します。
  • Derived は文字列を変更しようとします。
  • 文字列のヒープ メモリを解放しようとします。

もちろん、これは文字列に限ったことではありません。それはほんの一例でした。1 つのランタイムが何かを割り当て、別のランタイムが割り当てを解除するシナリオでは、クラッシュが発生します。

ヒープ メモリは、基本クラスによって使用されるランタイムによって所有されます。派生クラスのランタイムがそれを解放しようとします -> インスタント クラッシュ。同じ C++ コンパイラでコンパイルされ、同じランタイムを使用する dll を提供するために、dll プロバイダーに翻弄されます。これはメンテナンスの悪夢です。

DLL クラス インターフェイスは、間違いなく史上最悪のアイデアです。

例外は次の 2 つだけです。

  • DCOM (または同じ考え方である純粋な抽象クラス) を使用します。
  • コード ツリー全体を管理できます。たとえば、dll と exe は同じソリューションでビルドされます。

それ以外の場合はすべて、DLL クラス インターフェイスはサポートの悪夢であり、災害が起こるのを待っています。

このスレッド はおそらく解決策を提案できると思います。

/MDすべてを同じコンパイラでコンパイルし、すべてのモジュールが同じランタイムを共有するように使用する場合は、C4275 を無視してかまいません。

于 2012-12-06T09:26:36.403 に答える