データメンバーをエクスポートするのは正しいですか？ （C ++）

Question

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

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

ただし、回答に感謝します。

Answer 1

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

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

Answer 2

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

今、クラスをエクスポートする費用を払っても構わないと思っているなら、静的データをエクスポートしても問題が悪化することはないと思います。おそらく、エクスポートできる種類の中で、静的定数をエクスポートするのが最も安全です。それでも、Timoが言っているように、あなたは今この実装に縛られているので、私はそれをやめたいです。

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

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

Answer 3

クラスの（非静的）データメンバーに対する

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