Блог

Вчера я был на собеседовании, где мой интервьюер (который, по общему признанию, не претендовал на звание эксперта по этому вопросу) заявил, что «VB.NET более слабо типизирован, чем C #» — (В то же время он не смог вспомнить пример).

Это утверждение показалось мне некорректным (особенно учитывая, что оба языка используют одни и те же библиотеки фреймворка для своих типов), и я посоветовал как таковой и что, возможно, его смутила опция включения / выключения Option Strict или Option Infer.

В то же время я знаю, что VB.NET имеет ситуации, когда он будет выполнять принудительное ввод типов, что иногда приводит к неожиданным результатам (хотя я также не могу вспомнить, при каких условиях) — (На самом деле, я думаю, я только что вспомнил, что это было в основном при выполнении арифметических операций с разными типами, тогда как другие языки заставят вас быть явным (?)).

Итак, не мог бы кто-нибудь, пожалуйста, уточнить, является ли VB.NET как-то более слабо типизирован, чем C #, и если да, то не могли бы вы привести примеры?

«Слабо типизированный» и «строго типизированный» фактически бессмысленны без уточнения. То, как они используются, обычно означает «система типов имеет функции, которые мне не нравятся» или «система типов имеет функции, которые мне нравятся». Похоже, что ваш интервьюер не имеет четкого представления о том, что означают эти термины, и поэтому, вероятно, не должен задавать вопросы о них в интервью.

Существует множество особенностей систем типов, которые разные люди называют «строго типизированными» по сравнению со «слабо типизированными». Например, некоторые люди говорят, что «строго типизированный» означает «каждый объект знает свой собственный тип во время выполнения». Некоторые люди говорят, что «строго типизированный» означает, что компилятор знает точный тип каждой переменной и выражения. Некоторые люди говорят, что это означает, что компилятор имеет неточные ограничения типа для каждой переменной и выражения. И так далее. Каждая особенность систем типов может считаться указывающей на «сильный».

Я предлагаю отказаться от всего необоснованного понятия «сильной» и «слабой» типизации и поговорить о том, что вы на самом деле имеете в виду.

Различия между системами типов C # и VB невелики, особенно после добавления ‘dynamic’ в C # 4.0. И C #, и VB используют систему типов CLR, в которой каждый объект знает свой собственный тип и в которой незаконные преобразования типов обнаруживаются средой выполнения (либо при выполнении кода, либо при его передаче через верификатор) и превращаются в исключения. Оба имеют одиночное наследование для классов и множественное наследование для интерфейсов. Оба делают различие между типами значений и ссылочными типами. И так далее.

Принципиальное различие между системами типов C # и VB заключается в том, что VB поддерживает необязательное сокращение времени статической проверки типов во время компиляции и откладывание проверки типов до времени выполнения, что больше похоже на язык с динамически типизированным интерфейсом. Это очень удобно при взаимодействии с объектными моделями, которые были разработаны для систем динамического типа. Мы добавили аналогичную функцию в C # 4.0, но в соответствии с исторической поддержкой статической типизации в C # 4.0 эта функция основана на статическом вводе определенных выражений как «динамических», которые затем разрешаются путем повторного запуска анализатора типов во время выполнения и выполнения анализа типов для живых объектов.

Больше на эту тему можно найти в моем блоге:

http://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/

В качестве стратегии собеседования было бы лучше сказать «вы правы, он более слабо типизирован, но только для определенных настроек, таких как опция Strict Off или Опция Infer off»

Большинству людей приятнее, когда им говорят «вы правы», а не «вы запутались» 🙂

(Я никогда раньше не использовал VB, так что для меня это тоже в новинку)

Они ссылаются на инструкцию Option Strict, или, скорее, на то, что происходит, когда вы ее опускаете.

Следующий VB компилируется и выполняется идеально до тех пор, пока у вас есть Option Explicit выключенный:

 Class Widget
    Sub Method1()

    End Sub
End Class

Sub Main()
    Dim someInt As Integer
    Dim someDouble As Double
    Dim someObj As Object = New Widget

    someDouble = 1234567890.9876542
    someInt = someDouble
    Call someObj.Method1()
    Call someObj.Method2() ' causes runtime error
End Sub
  

Приведенное выше неявно преобразует double в целое число, вызывает метод Method1 по Object ссылке и даже вызывает метод Method2 (который даже не существует) — ни один из которых не будет компилироваться в C # или в VB с Option Strict On .

Это определенно соответствует определению «не такой строго типизированный«, как C #, хотя термин кажется довольно субъективным.

Обновление: Мы можем использовать ILSpy, чтобы раскрыть происходящее здесь «волшебство», посмотрев на скомпилированную сборку (на C #):

 object obj = new Module1.Widget();
double num = 1234567890.9876542;
int i = Math.Round(num);
NewLateBinding.LateCall(obj, null, "Method1", new object[0], null, null, null, true);
NewLateBinding.LateCall(obj, null, "Method2", new object[0], null, null, null, true);
  

Это объясняет, почему VB.Net compiler способен делать вещи, которые в противном случае казались бы незаконными в среде CLR, хотя, похоже, это приводит к некоторому снижению производительности во время выполнения.

VB.NET допускает оба варианта. Как упоминалось в комментариях, вы можете установить это в проекте (или файле), установив Option Strict либо ВКЛ., либо ВЫКЛ.

В документации MSDN здесь немного подробнее рассказывается о том, что делает этот параметр.