VB6はコンパイル時にオブジェクト型の対応をチェックしないのはなぜですか？

Question

私はまだVisual Basic 6を扱わなければなりません。

私はオブジェクトタイプの対応が実行時にのみ適用されることを知りました。例えば、this questionを参照してください。

---

私はこれを見つけるのにかなりショックを受けましたが、私は常にオブジェクトのタイプセーフチェックに頼っていました。

これはアーキテクチャ上の理由があるかどうか誰かが知っていますか（少なくとも複雑な問題になります）？

多型が関与していると分かりますが、パラメータの型が他の実装されていないクラスの場合、コンパイル時に型チェックに問題はありません...？

Answer 1

歴史の授業

VBバージョン1から3は厳しいでした。型の整合性チェックは実行時に行われましたが、より厳しいものでした。文字列を整数に代入すると、実行時エラーが発生します。整合性チェックが実行時にのみ行われた理由はわかりません - コンパイル時のチェックは実装が難しいと思います。

VBバージョン4では、文字列を整数に割り当てるとエラーは発生しませんが、暗黙的に文字列値が整数に変換されるように言語が変更されました。たとえば、文字列が"0"または""の場合、0に変換されます。文字列が含まれている場合、たとえば"1E40"とすると、オーバーフローエラーが発生します。多くのVBプログラマ（erm、私を含む）はこの変更を嫌って、それを悪の型強制と呼んだ。例えば。 Karl Petersonの指導者であるarticleを参照してください。

アーキテクチャ上のアプローチは、「実行時に型を推測で変換しようとすると、不可能な場合にのみエラーを発生させる」というものでした。つまり、のチェックは実行時にとなります。原則として、コンパイラは、オブジェクト型がプライベートで他のクラスでは実装されていないケースを検出し、コンパイル時にそれをチェックすることができますが、コンパイラ開発者の優先順位ではないと思います。開発者は、実行時にいくつかの割り当てがチェックされた理由と、コンパイル時に他のものがチェックされた理由を理解することが紛らわしいかもしれません。

VB.Netでは、既定の動作は従来のコードを簡単にアップグレードできるようにVB6と同じです。 Option Strict Onは、コンパイル時にチェックが行われるようにVB.Netで優先されます。コンパイル時のチェックは、間違いを早期に発見してしまうので便利です。

Answer 2

クラスは実装されておらず、クラスは実装されていません。 VB6クラスCarは、暗黙的に定義して、任意の外部のプロジェクト（DLL）で実装することができ、他のインターフェイス（税込_Boat）とコクラスにバンドルできるインターフェイス_CarますDim c As Carそれは、コンパイラによってインタフェース_Car使われていますされ

したがって、cは、Carクラスのインスタンスだけでなく、任意のオブジェクトの_Carインターフェイスへの参照を保持できます。例えば。と_Boatのインターフェイスを実装したコクラスMixをプログラムすることができます。Set c = New Mixがコンパイルされて実行されるため、では_BoatのQIが実際に成功します（「キャスト」が成功したとみなされます）。

_Carおよび_Boatは継承のどのフォームにも束縛されていないため、これはアップキャストでもダウンキャストでもありません。しかし、これはCOMがあなたがIUnknownインターフェイスを通して達成することを可能にするものです。

最近の言語では、コードでダウンキャストを明示的に要求する（そうでなければコンパイルエラーが発生する）ことを拒否しました。また、「サイドキャスト」（挑戦された車/ボートの例のように）脚に自分自身。