Псевдонимы(алиасы) в перечисления - правила использования

Всем привет! Сейчас изучаю перечисления в c# и хотел спросить, почему в с# можно использовать псевдоним для любого целого типа данных

(byte, sbyte, short, ushort, int, uint, long, ulong) , но нельзя

использовать любой системный целый тип данных C# (Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64) ?

Когда я смотрел видео урок, то там был такой пример-объяснение: "Представте себе ситуацию в которой возможно, Вы захотите отказаться от Framework-ов предоставляемых Microsoft в языке c# и отключите импорт всех библиотек и в том числе импорт библиотеки System, и решите создавать свои типы. Вы ведь можете создавать свои типы? Конечно же да, но при этом у вас должны остаться простейшие типы данных. Так вот, простейшие типы даннных(даже при отключенной библиотеке System) у вас все же останутся, но в виде алиасов, а не в виде полноценной структуры (например byte) которая входит в пространство имен System. ". Почему при таком подробном описании ситуации я это все спрашиваю? Дело в том, что далее по уроку автор уделил теме алиасов еще некоторое время (а сам автор страдает забывчивостью сказать что то важное и иногда к сожалению обладает некоторой степенью недосказанности по некоторым вопросам)

Вот в чем мой вопрос: Есть ли еще причины (помимо вышеприведенного примера) почему в перечислениях используют алиасы(псевдонимы)?

0

Баг такой был, говорят. И есть до сих пор, потому что толку от его исправления нет.

Posted by Microsoft on 6/25/2010 at 8:53 AM Thanks for the suggestion for Visual Studio! As you point out, we could enable support for saying Int16 instead of int here, but this would not provide any extra expressiveness to C# programs (and it's more characters to type!). We'd be unlikely to invest our resources to add this support to Enums.

0

BadCats, если я правильно понимаю тебя интересует почему можно написать enum Smth : int { ... }, но нельзя написать enum Smth : Int32 { ... }. Если разрешить второй вариант, то можно будет написать такой код, который компилятору придется проверять.
При компиляции такого кода компилятору придется убедиться что Int32 это System.Int32, а не что-то другое. Чтобю упростить жизнь и программисту и кмпилятору проще разрешить "наследование" только от встроенных типов. Спенарий с заменой базовой библиотеки тоже стоит учитывать, но он все таки может встретиться гораздо реже чем попытка указать неправильный типы для enum.

2

Жизнь они упростили только компилятору Программисты же ломают головы, изыскивая в запрете Int32 и разрешении int тайный смысл.
Это всё равно не наследование. Код с типами и их алиасами компилируется из
в такой IL
Т.е. компилятор и о заменяемости uint <> System.UInt32 знает, и enum на самом деле наследует от System.Enum.
А якобы переносимость без стандартных типов будет какая-то теоретическая, сферическая и в вакууме. Вроде бы и можно её сделать, но никому нафиг не надо.

1

т.е, когда я использую алиасы в перечислениях, то теоретически работа компилятора будет идти быстрее т.к компилятору не придется проверять что Int32 это System.Int32 или я ошибаюсь?

0

BadCats, о скорости Вам беспокоиться не стоит.
У них баг. Баг всех устраивает. Всё нормально. Улыбаемся и машем.

1

можно ссылку на источник?

0

https://connect.microsoft.com/... stem-int64
https://connect.microsoft.com/... -type-name
- эти ссылки уже не работают, за что спасибо MS. Может быть в архиве каком-нибудь найдёте.

http://stackoverflow.com/quest... on-to-long

https://social.msdn.microsoft.... rplanguage - здесь закончилось призывом модератора принять всё как есть и верить MS святоликому. Меня, впрочем, не убедило.

1

BadCats, ошибаешься, компилятор всегда работает с полными именами.

0

простите не понял. Можно пожалуйста подробнее?

0

BadCats, int == Int32 == System.Int32. Сокращенные записи существуют только для программиста.

Добавлено через 28 минут
BadCats, кстати var туда же. Компилятор и так и так выводит тип, поэтому если кто думает, что не используя var упрощает задачу компилятору - то он сильно ошибается. Или не использует юзинги - что с ними, что без них, скорость будет одна и та же. Причем для компилятора все типы характеризуются просто числом - уникальным идентификатором. Если точнее - адресом VTable в памяти И вот с этим числом работает компилятор. А все эти строки существуют только для работы с ними людей.

2

нашел! на archive.org Это оно?
https://web.archive.org/web/20... stem-int64

0

Да, оно.
Как видите, "by design" и "won't fix".

Добавлено через 12 минут

As you point out, we could enable support for saying Int16 instead of int here, but this would not provide any extra expressiveness to C# programs (and it's more characters to type!). We'd be unlikely to invest our resources to add this support to Enums. Alex Turner Program Manager Visual Basic and C# Compiler

Т.е. могли бы исправить, но профита нет от этого, так что тратить время на исправление не хотят. Это ответ на вопрос темы. Нет никакого тайного смысла, мирового заговора и расчёта на портирование языка. Всё банально.

1

Сообщение от Rius https://social.msdn.microsoft.com/Fo...csharplanguage - здесь закончилось призывом модератора принять всё как есть и верить MS святоликому. Меня, впрочем, не убедило.

Привет Ruis, переводил данную тобой тему на "Великий и могучий", и хотелось бы узнаттьь твое мнение по поводу данного высказывания:

Well, technically speaking System.Int16 is a value type ﴾structure﴿ which has one 'short' field. You cannot use value type as enum underlying type ‐ IMO that's why you get the error. This is definitely the reason why you cannot do this in IL language. However I can imagine that a .NET language could choose to hide this technical difference from developer in that language. C# didn't choose to hide it in this case. If you want to know why, I'd recommend to ask on C# language forum. ‐Karel

ответ:

"short" and "System.Int16" are one and the same. They are both value types ‐ "short" is just an alias for the System.Int16 value type. I'm not sure what you mean when you say that System.Int16 has one 'short' field ‐ it doesn't ‐ it has the same members and fields as 'short' since it's the same type.

ответ на ответ:

You are right that C# considers 'short' as alias for 'System.Int16' ﴾as this MSDN doc mentions﴿. Therefore this particular question should be probably raised on C# forum. I interpreted 'short' as equivalent to 'signed 16‐bit integer' which is named 'int16' in IL/CLI, where it is indeed different: int16 and System.Int16 are tight together, but technically they are not the same in CLI. int16 corresponds to the unboxed value type System.Int16. Note that System.Int16 cannot be used at many places where int16 ﴾ELEMENT_TYPE_I2﴿ can be used ﴾e.g. in signatures and custom attributes encoding﴿. On the other hand int16 ﴾ELEMENT_TYPE_I2﴿ cannot be used for method calls, because it is not a BCL type. That's where System.Int16 comes handy. You can also confirm that by running ildasm.exe on mscorlib.dll. Here's how System.Int16 is defined: Code 1 2 3 4 5 6 7 8 9 10 11 .class public sequential ansi serializable sealed beforefieldinit System.Int16 extends System.ValueType implements System.IComparable, System.IFormattable, System.IConvertible, class System.IComparable`1<int16>, class System.IEquatable`1<int16> { .field assembly int16 m_value // Note: This is not recursive definition // And more ... } Sorry for the confusion, ‐Karel

Мне нужно твое мнение по поводу этих цитат. Всем Заранее Спасибо!
все остальные кстати тоже могу высказываться
мне необходимо узнать: есть ли крупица смысла(смысла про то, что в IL коде это все же разные типы) в этих цитатах-предположениях или это просто бред?

0

BadCats, ну почему, человека понять можно. Он говорит о том, что для программиста short и Int16 это один и тот же тип, но для рантайма это разные вещи. Из шарпа ты отличий никогда не увидишь, потому что на уровне языка это опять же одно и то же (примитивное typeof(short) == typeof(Int16) это подтвердит), а вот на нижележащих уровнях это разные вещи, потому что Int16 - это структура, в которую упаковывается "настоящее" число при боксинге, а при анбоксинге соответственно оно достается. Соответственно т.к. вызовы методов (по крайней мере через интерфейс) без боксинга невозможны, то и вызывать их можно только на "взрослой" структуре. Про случаи, когда можно использовать только число, но нельзя структуру немного не понял - слишком низкоуровневые вещи затронуты.

0

Может я сейчас напишу ОЧЕНЬ БОЛЬШУЮ ГЛУПОСТЬ, но каким боком это к несовместимости (в версии C# младше 6.0) алиасов и "полноценных типов" в перичеслениях? Короче вопрос всей этой темы, приминительно к этим ответам на иностранном MSDN

0

Судя по всему данное ограничение было убрано в C# 6.0: источник.

0