1

私はカスタムイベントをC++/ CLIで書いています（私はほとんどadd / removeメソッドだけを気にしています）：

    event EventHandler<XyzEventArgs^> ^Xyz
    {
        void add(EventHandler<XyzEventArgs^> ^handler);
        void remove(EventHandler<XyzEventArgs^> ^handler);
        void raise(Object ^sender, XyzEventArgs ^e);
    }

すべてがうまく機能しますが、C＃でIntellisenseを見ると、見苦しいパブリックraise_Xyzメソッドが表示されます。

イベントを非公開にせずにそれを隠す方法について何かアイデアはありますか？

どんな助けでも大歓迎です。

編集：

パブリックraise_Xyzメソッドを別の可視性修飾子（私の場合は内部）でマークすることにより、それらを排除することができました。これは、クラスの外部からイベントを発生させることができないことを意味します。それは私にとっては大丈夫です。しかし、私は単純なイベントでさえ気づきました

public:
event EventHandler ^XXX;

raise_XXXメソッドを生成し、それらは保護されます。それを防ぐ方法はありますか？

4

1 に答える 1

3

これはECMA-372仕様にも当てはまることに注意してください。c＃4は、コンパイラによって作成されたイベントメカニズムのスキャフォールドを変更するため、C ++/CLIのスキャフォールドも変更される可能性があります

イベントは、関連するスキャフォールドを生成するコンパイラーによって処理されるため（または、イベントに対して独自のスキャフォールドを実行できるようにするため）、必然的に、これを行うために生成される一連のメソッドがあります。

C ++ / CLIは、他のほとんどの.Net言語とは異なり、イベントシュガーを使用すると、サブクラスで基本クラスで宣言されたイベントを発生させることができます。

    public ref class Class1
    {
    public:
        event EventHandler^ MyEvent;
    };

    public ref class Class2 : Class1
    {
    public:
        void Foo()
        {
            this->MyEvent(this, gcnew System::EventArgs());
        }
    };

これは問題なくコンパイル（および実行）されます。同等のC＃と比較してください

    public class Class1
    {
        public event EventHandler MyEvent;
    }

    public class Class2 : Class1
    {
        public void Foo()
        {
        base.MyEvent(this, new System::EventArgs());
        }
    }

これは、次のようにコンパイルすることを拒否します。

イベント「Class1.MyEvent」は、+ =または-=の左側にのみ表示できます（タイプ「Class1」内から使用する場合を除く）

C ++ / CLIでこれを行うには、raise_Xxxメソッドを保護されたものとして公開する必要があります。デフォルトでイベントを維持する基になるデリゲートフィールドを公開することは危険であるだけでなく、自動デリゲートバッキングフィールドなしで独自の方法でイベントを実装するクラスの柔軟性を許可しません。

サブクラスがこれを実行できるようにしたくない（または表示できないようにする）場合は、サブクラスを内部にすることは、アセンブリの外部にあるコードの効果的なソリューションです。

C ++ CLI仕様では、イベントスキャフォールディングの命名規則が定義されていることに注意してください。

18.2.2イベント用に予約されたメンバー名

イベントE（§18.5）の場合、次の名前が予約されています。

  • add_E
  • remove_E
  • raise_E

したがって、これは変更できるものではありません

于 2009-02-24T14:37:52.533 に答える