5

日中の仕事では、私たちが作成した多数のライブラリを使用する VB6 アプリケーションに取り組んでいます (これも輝かしい VB6 です)。これらのサポート ライブラリの 1 つに、パブリック プロパティを介して公開された多数のプライベート メンバーがあり、そのプロパティを削除し、プライベート メンバー変数を元のプロパティと同じ名前のパブリック フィールドに昇格するように求められました。

さて、私は COM の専門家ではありませんが、クラスで公開されているすべての項目が独自の GUID を取得するという印象を受けました。各値が 2 つの Guid (Property Get と Property Let) から 1 つ (public フィールド) のみを使用する状況に移行するため、バイナリ互換性が損なわれると予想していましたが、そうではないようですやってない。

誰でも理由を説明できますか？

4

2 に答える 2

7

いいえ、プロパティgetメソッドとproperty letメソッドが削除されていないため、互換性が損なわれていません。コンパイラがあなたのためにそれらを書いているだけです。

これは、VB6が.Netよりも間違いなく優れている数少ない分野の1つではありませんか？

  • .Netでは、パブリックフィールドはパブリックプロパティとは異なる動作をするため、一部のリファクタリングが困難になり、混乱が生じます。
  • VB6では、パブリックフィールドはパブリックプロパティとまったく同じように動作します。そのため、バイナリ互換性に影響を与えることなく切り替えることができます。舞台裏では、コンパイラはパブリックフィールドのプロパティgetおよびsetルーチンを生成します。ある意味で、VB6は自動的にプロパティを実装しました（現在、VB10では「新機能」としてアドバタイズされています）...
于 2010-05-26T16:35:55.077 に答える
1

それよりは微妙だと思います。COM インターフェイスの GUID を取得します (個々のフィールド/メソッドごとではありません)。私が理解しているように、現在コンパイルしているインターフェイスがDLLの参照バージョンと下位互換性がある場合（1つあると仮定）、互換性がない場合にのみGUIDを変更する場合、バイナリ互換性は解決しようとします。

したがって、すべての get/set メソッドの削除が互換性があると判断したことにも驚いています :/

于 2010-05-26T15:34:42.577 に答える