Является ли VB.NET слабо типизированным по сравнению с C # - PullRequest
6 голосов
/ 15 апреля 2011

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

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

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

Так может кто-то пояснить, является ли VB.NET более слабо набранным шрифтом, чем C #, и если да, можете ли вы привести примеры?

Ответы [ 4 ]

16 голосов
/ 15 апреля 2011

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

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

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

Различия между системами типов C # и VB незначительны, особенно с учетом добавления «динамического» в 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/

4 голосов
/ 15 апреля 2011

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

Большинство людейсчастливее, когда тебе говорят "ты прав", а не "ты запутался":)

4 голосов
/ 15 апреля 2011

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

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

Следующий VB компилирует и запускает perfeclty до тех пор, пока у вас отключено 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 способен делать вещи, которые в противном случае кажутся недопустимыми в CLR, хотя, похоже, он приводит к некоторому снижению производительности во время выполнения.

1 голос
/ 15 апреля 2011

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

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

...