誤解されているので、明確にしなければなりません。以下のすべてのソリューションでは、オブジェクトを再コンパイルする必要はありません。コードでクラスを使用するには、オブジェクト ファイルにコンパイルされている場合、そのクラスの宣言と共にヘッダー ファイルをインクルードする必要があります。
#include <class.h>
ObjectFoo instance;
クラス自体を再コンパイルせずに、ヘッダーを変更する (a) か、ヘッダーを別の場所にコピーしてそのヘッダーを含める (b)ことは可能です (ただし、注意しないと危険です) 。
#include <class_fixed.h>
ObjectFoo instance;
新しいヘッダーをインクルードしたコードは、(再コンパイルしていない) オブジェクト ファイル内に として宣言されたクラスの実装があると考えclass_fixed.h
ます。のように宣言されたクラスが存在しますが、class.h
. 新しいヘッダーでメンバーのオフセットを変更 (たとえば、新しいメンバーを追加) すると、コードが正しく機能しなくなります。ただし、アクセスを変更するだけで問題なく動作します。コンパイルされたコードはアクセスについて知りません。これはコンパイル時にのみ問題になります。
これは必ずしも有害ではありません。日常生活では、ライブラリの新しいバージョンをシステムにインストールし、それに依存するすべてのプログラムを再コンパイルしないと、このような変化に遭遇します。しかし、取り扱いには注意が必要です
いくつかの解決策があります。
memcpy()
しないでください!オブジェクトのコピーは、クラス設計者によって課された特定のポリシーに従う場合があるため、memcpy は使用しないでください。たとえば、auto_ptr
sは単に memcopy することはできません。memcopyauto_ptr
を実行してから両方に対してデストラクタを実行すると、同じメモリを 2 回解放しようとするため、プログラムがクラッシュします。
ヘッダーまたはマクロを使用して変更private:
するライセンスで許可されている場合は、クラスの実装に付属するヘッダー ファイルを編集することで問題を解決できます。実装のソース コード (つまり、クラスの cpp ファイル) が制御下にあるかどうかは問題ではありません。データ メンバー (ヘッダー内) のプライベートをパブリックに変更するだけで十分であり、バイナリが与えられた場合でも問題なく動作します。クラス定義を含む唯一のライブラリ。(メンバー関数の場合、アクセスを変更すると内部名が変更されることがありますが、MSVS と GCC の場合は問題ありません。)public:
新しいゲッター関数の追加へ の
変更はほとんどの場合問題ありませんが (クラスにアクセス可能な特定のメンバーがある場合にコンパイルを中断する特定のコンパイル時のチェックに依存しない限り)、新しいゲッター関数の追加は慎重に実行する必要があります。getter 関数はインラインである必要があります(したがって、クラスのヘッダー ファイルで定義されます)。private
public
reinterpret_cast
キャストの時点での実際のインスタンスが特定のコードのクラスから派生できる動的基底クラス (動的とは「仮想関数または基底を使用する」ことを意味します) へのポインターをキャストしない場合、キャストは問題なく機能します。
protected:
そして忘れてしまった場合に備えて。C++ は members を宣言できprotected:
ます。つまり、指定されたから派生したクラスにのみアクセスできます。これはあなたのニーズを満たすかもしれません。