Интересные моменты в C# (boxing unboxing)

[@mayorovp]

Еще по поводу распаковки Nullable. Ключевое слово as работает с такими типами, значение null получается при любой неудачной распаковке:

object box = 42L;
int? unbox = box as int?; // null

Это довольно удобно при работе с ADO.NET, поскольку значение DBNull автоматически превращается в обычный null во время распаковки.

[@Fedorkov]

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

Тестовый код:
object box = (int)42; long unbox = (long)box;

Вы так и не ответили на свой вопрос: что будет при запуске кода? Если будет ошибка компиляции с очевидным сообщением, то всё остальное запоминать не нужно, и задвать такие вопросы на собеседовани — трата времени всех участвующих.

То есть информация, конечно, интересная и полезная, но не то чтобы очень важная.

[@mynameco]

Будет исключение времени выполнения.

[@boblenin]

А конкретнее InvalidCastException.

[@Fedorkov]

Тогда OK, но это стоит добавить в статью.

[@int19h]

Подобное поведение при распаковке не является частью стандарта языка. Т.е., да, оно работает, но это незадокументированное расширение, и полагаться на него не стоит. Аналогично с приведением массивов, когда int[] можно успешно скастить к uint[] через object.

А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:

object x = (int)123;
object x = (int?)123;

Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.

Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.

[@mynameco]

Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.

Вы же сами сказали что его нет в документации.

[@int19h]

Про Nullable как раз все есть.

А про то, чего нет, потому и лучше читать документацию, что вы потом в коде не будете закладываться на вещи, которые сегодня есть, а завтра их нет :)

Нет, понятно, что иногда бывает интересно ковыряться в такого рода деталях, как и в различных вариантах undefined behavior в C++. Но это надо подавать соответствующим образом — не «C# это поддерживает», а «посмотрите, какой забавный глюк».

[@mynameco]

Я не собираюсь это использовать. Статья называется «интересные моменты» а не «правильное использование». С Уважением.

[@Sing]

> Представьте себе удивление человека, когда вы ему напишете другой правильный вариант.

Давайте назовём это «работающий вариант», а не «правильный»? А то ведь начнут писать так.

Для ещё худшей читаемости кода надо было назвать enum, скажем, StringType.