厄介な問題を回避するために、C# から C++ にいくつかのコードをバックポートしようとしています。
使用中の it の例を次に示します。
internal int InternalArray__ICollection_get_Count ()
{
return Length;
}
厄介な問題を回避するために、C# から C++ にいくつかのコードをバックポートしようとしています。
使用中の it の例を次に示します。
internal int InternalArray__ICollection_get_Count ()
{
return Length;
}
internal
C++には に直接相当するものはありません。public
//別の唯一のアクセス制御メカニズムは、protected
特定のクラスが独自のクラスのすべてのメンバーにアクセスできるようにするメカニズムです。private
friend
したがって、のinternal
ようなアクセス制御メカニズムとして使用できますが、大きな違いは次のとおりです。
friend
クラスを1つずつ明示的に宣言する必要がありますfriend
クラスは例外なくすべてのメンバーにアクセスできます。これは非常に高いレベルのアクセスであり、密結合を引き起こす可能性があります (これが、通常の反射反応friend
が「本当に必要ですか?」である理由です)。C++ で「フレンド」を使用する必要がある場合も参照してください。
モジュール全体を互いに分離することを考えている場合は、2 つのセットのヘッダー ファイルを保持してみてください。1 つは「パブリック」メソッドで、もう 1 つは「内部」メソッドです。この時点で重複を避ける方法がわかりません。私の知る限り、クラスはコンパイル単位で 1 回しか宣言できず、パブリック ヘッダーと内部ヘッダーの両方にクラスの完全な定義が必要です。_Foo.public.h
確かに非常に不格好な方法の 1 つは、メソッド宣言のみを含むおよびのような部分ファイルを作成_Foo.internal.h
し、「実際の」ヘッダー ファイルにクラス宣言本体にそれらの 1 つまたは両方を含めることです。
class Foo {
#include "_foo.public.h"
}
class Foo {
#include "_foo.internal.h"
}
ソース ファイルは、独自のモジュールの内部ヘッダーを参照しますが、依存関係の公開ヘッダーを参照します。プロジェクトのレイアウトとビルド スクリプトを微調整して、これを適度に透明にすることができるはずです。(たとえば、各モジュールの正しいディレクトリへのインクルード パスを設定します。)
これは、実際のアクセス制御を実装する代わりに「内部」メンバーを非表示にするだけであり、モジュールが個別にコンパイルされ、バイナリ依存関係として扱われることを前提としています。依存関係をソース ツリーに含めてすべてを一度にコンパイルすることで依存関係を処理する場合は、とにかくそれらをビルドできる必要があり、内部メソッド宣言がビルドにまだ存在する可能性があります。