c++ - データ メンバーをエクスポートするのは正しいですか? (C++)

Question

タイトルが示すように、C++ クラス内から静的データをインポート/エクスポートすることは正しいですか、または有効ですか?

私の問題を発見しました - 私が見ていたクラスの作成者は、このプラットフォームではサポートされていない書き込み可能な静的データをエクスポートしようとしていました。

しかし、応答に感謝します。

Answer 1

エクスポートされたC++クラスは、名前のマングリングやその他の問題のために、DLLクライアントがDLLと同じコンパイラを使用する必要があることを意味します。これは実際にはかなり大きな問題です。DLL自体がMSVC71を使用しているときに、クライアントプログラムがMSVC9に切り替わったため、C++クラスの束にCラッパーを作成する必要がありました。[DLLをMSVC90に切り替えることには他にもいくつかの問題がありました]。それ以来、私はクラスをエクスポートするこのビジネスにかなり懐疑的であり、すべてに対してCラッパーを作成することを好みます。

さて、クラスのエクスポートの代償を払っても構わないと思っているのであれば、静的データのエクスポートによって問題が悪化することはないと思います。間違いなく、エクスポートできるものの中で、静的定数をエクスポートするのが最も安全です。それでも、Timoが言うように、あなたは今この実装に閉じ込められているので、私はそれをしたくありません。

私が取り組んだフレームワークの1つでは、クライアントが一連のエラーコード定数を提供する必要がありました。時間の経過とともに、単純な定数の束を使用するのは非常に脆弱であることがわかり、オブジェクト指向デザインに切り替えました。共通のエラーコードを返すデフォルトの実装がありましたが、各エラーコードは、個々のクライアントによってオーバーライドできる仮想関数を使用してアクセスされ、高度なデバイス固有のエラー処理から使用されました。このソリューションは、定数のエクスポートに基づくソリューションよりもはるかにスケーラブルであることが証明されました。

静的変数をエクスポートする前に、コンポーネントがどのように進化するかについて、じっくり考えてみることをお勧めします。

Answer 2

それが機能し、あなたが期待することをする限り、それは正しいですか？クラスまたはクラスメンバーで_declspec（dllexport / dllimport）を使用することについて話していると仮定すると、そうです、そうすることができ、期待される結果が得られるはずです-静的データはdllの外部からアクセスでき、他のC++コードはアクセスできますC ++アクセス仕様（パブリック/保護/プライベート）がそもそも外部アクセスをブロックしないことを条件としました。

それは良い考えですか？個人的には、ライブラリ内だけでなく外部にもクラスの内部を公開することになるとは思いません。つまり、1日の終わりに実装の詳細を変更することはほとんど不可能です。このクラスのインターフェースとその実装の大部分が決して変更されないかどうかを100％確信しているかどうかを自問してください...

Answer 3

クラスの (非静的) データ メンバーに対する dllexport (またはインポート) は何もしません。エクスポートされた「もの」は、関数またはグローバル データのいずれかです (ただし、これは疑わしい設計上の選択です)。クラスの dllexport は、「これらの関数をすべてエクスポートする」というショートカットです。