Неявное приведение типов в VB.NET

Вопрос предназначен для ленивых программистов VB. Пожалуйста.

В vb я могу это сделать, и у меня не будет никаких ошибок.

Пример 1

Dim x As String = 5
Dim y As Integer = "5"
Dim b As Boolean = "True"

Пример 2

Dim a As EnumType = 4
Dim v As Integer = EnumType.EnumValue

Пример 3

Private Sub ButtonClick(sender As Object, e As EventArgs)
    Dim btn As Button = sender        
End Sub

Пример 4

Private Sub ButtonClick(sender As Button, e As EventArgs)
    Dim data As Contact = sender.Tag
End Sub

Если я точно знаю ожидаемый тип среды выполнения, разве это «запрещено» полагаться на встроенное приведение типов vb-языка? Когда я могу положиться?


vb.net implicit-conversion late-binding
person Shimmy Weitzhandler    schedule 12.04.2010    source источник
comment
Вы можете расширить этот вопрос: можете ли вы полагаться на параметры по умолчанию? Например, запись (имя поля), запись! Имя поля, abc (1) и т. Д.   -  person Mark Hurd    schedule 12.04.2010
comment
Я не понял, что вы имеете в виду, полагаясь на параметры по умолчанию, конечно, можете, это то, что они намереваются гарантировать, но вы должны проверить нулевое значение, поскольку оно может быть обнулено пользовательским кодом: CallMethod (3, 4, Ничего такого)   -  person Shimmy Weitzhandler    schedule 12.04.2010
comment
Извините, я имел в виду свойства по умолчанию, как видно из моих примеров.   -  person Mark Hurd    schedule 22.04.2010

Ответы (4)


arrow_upward
1
arrow_downward

Комментарий к отметке J перейти к ответу за OP

Не стесняйтесь полагаться на это все, что хотите, просто убедитесь, что вы знаете правила того, что делает неявное приведение. Тем не менее, пример №4 выглядит очень легко взломать в будущем, я был бы намного счастлив, если бы раньше была хотя бы нулевая проверка.

person Chris Haas    schedule 12.04.2010

arrow_upward
3
arrow_downward

Конечно, не «запрещено» использовать Option Strict Off, но почти каждый настоятельно рекомендует использовать Option Strict On.

Причины объясняются в других вопросах, например this.

person MarkJ    schedule 12.04.2010
comment
Согласитесь, это не запрещено, это просто неодобрительно. Не стесняйтесь полагаться на это все, что хотите, просто убедитесь, что вы знаете правила того, что делает неявное приведение. Тем не менее, пример №4 выглядит очень легко взломать в будущем, я был бы намного счастлив, если бы раньше была хотя бы нулевая проверка. - person Chris Haas; 12.04.2010
comment
@ Крис, если бы ты разместил свой пост отдельно, я бы отметил его как ответ. - person Shimmy Weitzhandler; 12.04.2010
comment
Спасибо @Shimmy, перешли к ответу сейчас - person Chris Haas; 12.04.2010

arrow_upward
0
arrow_downward

Если вы используете Visual Basic 2008, другой вариант - это явное приведение типов (например, Option Strict On) и полагаться на Option Implicit On, поэтому вам не нужно писать тип дважды.

Dim x = 5.ToString()  
Dim data = DirectCast(sender.Tag, Contact)
person ggf31416    schedule 12.04.2010

arrow_upward
0
arrow_downward

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

Обдумывание всех возможных последствий и обработка почти неизбежных ошибок, вероятно, займет больше времени, чем просто строгий ввод переменных, строгая проверка ваших входных данных и явное приведение типов там, где это необходимо.

person John M Gant    schedule 12.04.2010
comment
Я не уверена. Бьюсь об заклад, вы C # er. Тот же риск, на который я бы пошел при явном приведении переменной (зачем я приводил, потому что я знаю ожидаемый тип), я могу полагаться на встроенную функцию автоматического приведения lang, и поэтому я являюсь VBer, и я такой пристрастился к нему. Я просто хотел убедиться, что он официально не устарел. - person Shimmy Weitzhandler; 13.04.2010