Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Еще по поводу распаковки Nullable. Ключевое слово
Это довольно удобно при работе с ADO.NET, поскольку значение
as работает с такими типами, значение null получается при любой неудачной распаковке:object box = 42L;
int? unbox = box as int?; // null
Это довольно удобно при работе с ADO.NET, поскольку значение
DBNull автоматически превращается в обычный null во время распаковки.
Типичный вопрос на собеседовании об упаковке и распаковке выглядит следующим образом — «Что будет при запуске данного кода, и если он не будет работать то как его исправить?».
Тестовый код:
object box = (int)42; long unbox = (long)box;
Вы так и не ответили на свой вопрос: что будет при запуске кода? Если будет ошибка компиляции с очевидным сообщением, то всё остальное запоминать не нужно, и задвать такие вопросы на собеседовани — трата времени всех участвующих.
То есть информация, конечно, интересная и полезная, но не то чтобы очень важная.
Подобное поведение при распаковке не является частью стандарта языка. Т.е., да, оно работает, но это незадокументированное расширение, и полагаться на него не стоит. Аналогично с приведением массивов, когда int[] можно успешно скастить к uint[] через object.
А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:
Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.
Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.
А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:
object x = (int)123;
object x = (int?)123;
Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.
Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.
Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.
Вы же сами сказали что его нет в документации.
Про Nullable как раз все есть.
А про то, чего нет, потому и лучше читать документацию, что вы потом в коде не будете закладываться на вещи, которые сегодня есть, а завтра их нет :)
Нет, понятно, что иногда бывает интересно ковыряться в такого рода деталях, как и в различных вариантах undefined behavior в C++. Но это надо подавать соответствующим образом — не «C# это поддерживает», а «посмотрите, какой забавный глюк».
А про то, чего нет, потому и лучше читать документацию, что вы потом в коде не будете закладываться на вещи, которые сегодня есть, а завтра их нет :)
Нет, понятно, что иногда бывает интересно ковыряться в такого рода деталях, как и в различных вариантах undefined behavior в C++. Но это надо подавать соответствующим образом — не «C# это поддерживает», а «посмотрите, какой забавный глюк».
> Представьте себе удивление человека, когда вы ему напишете другой правильный вариант.
Давайте назовём это «работающий вариант», а не «правильный»? А то ведь начнут писать так.
Для ещё худшей читаемости кода надо было назвать enum, скажем, StringType.
Давайте назовём это «работающий вариант», а не «правильный»? А то ведь начнут писать так.
Для ещё худшей читаемости кода надо было назвать enum, скажем, StringType.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интересные моменты в C# (boxing unboxing)