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

@BadCats · Регистрация: 31.01.2016

Author24 — интернет-сервис помощи студентам

Всем привет! Сейчас изучаю перечисления в 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. ". Почему при таком подробном описании ситуации я это все спрашиваю? Дело в том, что далее по уроку автор уделил теме алиасов еще некоторое время (а сам автор страдает забывчивостью сказать что то важное и иногда к сожалению обладает некоторой степенью недосказанности по некоторым вопросам)

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

@Rius · 17.02.2016, 21:48

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

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.

@OwenGlendower · 18.02.2016, 01:29

BadCats, если я правильно понимаю тебя интересует почему можно написать enum Smth : int { ... }, но нельзя написать enum Smth : Int32 { ... }. Если разрешить второй вариант, то можно будет написать такой код, который компилятору придется проверять.

C#

struct Int32
{
    // ...
}
 
enum Smth : Int32
{
    A, B, C
}

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

@Rius · 18.02.2016, 08:33

Жизнь они упростили только компилятору

Программисты же ломают головы, изыскивая в запрете Int32 и разрешении int тайный смысл.
Это всё равно не наследование. Код с типами и их алиасами компилируется из

C#

public enum Enum1 : short
{
    One,
    Two
}
 
public enum Enum2 : uint
{
    One,
    Two
}
 
struct Str1
{
    uint value1;
    System.UInt32 value2;
    short value3;
    System.Int16 value4;
}

в такой IL

C#

.class public auto ansi sealed Enum1
    extends [mscorlib]System.Enum
{
    // Fields
    .field public specialname rtspecialname int16 value__
    .field public static literal valuetype Enum1 One = int16(0)
    .field public static literal valuetype Enum1 Two = int16(1)
 
} // end of class Enum1
 
.class public auto ansi sealed Enum2
    extends [mscorlib]System.Enum
{
    // Fields
    .field public specialname rtspecialname uint32 value__
    .field public static literal valuetype Enum2 One = uint32(0)
    .field public static literal valuetype Enum2 Two = uint32(1)
 
} // end of class Enum2
 
.class private sequential ansi sealed beforefieldinit Str1
    extends [mscorlib]System.ValueType
{
    // Fields
    .field private uint32 value1
    .field private uint32 value2
    .field private int16 value3
    .field private int16 value4
 
} // end of class Str1

Т.е. компилятор и о заменяемости uint <> System.UInt32 знает, и enum на самом деле наследует от System.Enum.
А якобы переносимость без стандартных типов будет какая-то теоретическая, сферическая и в вакууме. Вроде бы и можно её сделать, но никому нафиг не надо.

@BadCats · 18.02.2016, 20:22 **[ТС]**

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

@Rius · 18.02.2016, 20:23

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

@BadCats · 22.02.2016, 20:39 **[ТС]**

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

@Rius · 22.02.2016, 20:51

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 святоликому. Меня, впрочем, не убедило.

Psilon · 22.02.2016, 20:53

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

@BadCats · 22.02.2016, 20:54 **[ТС]**

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

Psilon · 22.02.2016, 21:53

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

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

И вот с этим числом работает компилятор. А все эти строки существуют только для работы с ними людей.

@BadCats · 23.02.2016, 13:11 **[ТС]**

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

@Rius · 23.02.2016, 13:47

Да, оно.
Как видите, "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

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

@BadCats · 07.03.2016, 16:40 **[ТС]**

Сообщение от 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:

Код

.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 коде это все же разные типы) в этих цитатах-предположениях или это просто бред?

Psilon · 07.03.2016, 18:10

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

@BadCats · 07.03.2016, 21:35 **[ТС]**

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

Someone007 · 04.06.2016, 23:43

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

@BadCats 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	07.03.2016, 16:40 [ТС]	14
	Сообщение от 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: Код .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

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	07.03.2016, 18:10	15
	BadCats, ну почему, человека понять можно. Он говорит о том, что для программиста short и Int16 это один и тот же тип, но для рантайма это разные вещи. Из шарпа ты отличий никогда не увидишь, потому что на уровне языка это опять же одно и то же (примитивное typeof(short) == typeof(Int16) это подтвердит), а вот на нижележащих уровнях это разные вещи, потому что Int16 - это структура, в которую упаковывается "настоящее" число при боксинге, а при анбоксинге соответственно оно достается. Соответственно т.к. вызовы методов (по крайней мере через интерфейс) без боксинга невозможны, то и вызывать их можно только на "взрослой" структуре. Про случаи, когда можно использовать только число, но нельзя структуру немного не понял - слишком низкоуровневые вещи затронуты. 0

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

Решение

Решение

Решение

@Rius 10538 / 6466 / 1502 Регистрация: 25.05.2015 Сообщений: 19,598 Записей в блоге: 14
	17.02.2016, 21:48	2
	Баг такой был, говорят. И есть до сих пор, потому что толку от его исправления нет. 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 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	18.02.2016, 20:22 [ТС]	5
	т.е, когда я использую алиасы в перечислениях, то теоретически работа компилятора будет идти быстрее т.к компилятору не придется проверять что Int32 это System.Int32 или я ошибаюсь? 0

@Rius 10538 / 6466 / 1502 Регистрация: 25.05.2015 Сообщений: 19,598 Записей в блоге: 14
	18.02.2016, 20:23	6
	Сообщение было отмечено BadCats как решение Решение BadCats, о скорости Вам беспокоиться не стоит. У них баг. Баг всех устраивает. Всё нормально. Улыбаемся и машем. 1

@BadCats 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	22.02.2016, 20:39 [ТС]	7
	можно ссылку на источник? 0

@Rius 10538 / 6466 / 1502 Регистрация: 25.05.2015 Сообщений: 19,598 Записей в блоге: 14
	22.02.2016, 20:51	8
	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

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.02.2016, 20:53	9
	BadCats, ошибаешься, компилятор всегда работает с полными именами. 0

@BadCats 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	22.02.2016, 20:54 [ТС]	10
	простите не понял. Можно пожалуйста подробнее? 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.02.2016, 21:53	11
	BadCats, int == Int32 == System.Int32. Сокращенные записи существуют только для программиста. Добавлено через 28 минут BadCats, кстати var туда же. Компилятор и так и так выводит тип, поэтому если кто думает, что не используя var упрощает задачу компилятору - то он сильно ошибается. Или не использует юзинги - что с ними, что без них, скорость будет одна и та же. Причем для компилятора все типы характеризуются просто числом - уникальным идентификатором. Если точнее - адресом VTable в памяти И вот с этим числом работает компилятор. А все эти строки существуют только для работы с ними людей. 2

@BadCats 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	23.02.2016, 13:11 [ТС]	12
	нашел! на archive.org Это оно? https://web.archive.org/web/20... stem-int64 0

@Rius 10538 / 6466 / 1502 Регистрация: 25.05.2015 Сообщений: 19,598 Записей в блоге: 14
	23.02.2016, 13:47	13
	Да, оно. Как видите, "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

	04.06.2016, 23:43

Опции темы

@BadCats 2 / 2 / 1 Регистрация: 31.01.2016 Сообщений: 119
	07.03.2016, 21:35 [ТС]	16
	Может я сейчас напишу ОЧЕНЬ БОЛЬШУЮ ГЛУПОСТЬ, но каким боком это к несовместимости (в версии C# младше 6.0) алиасов и "полноценных типов" в перичеслениях? Короче вопрос всей этой темы, приминительно к этим ответам на иностранном MSDN 0

Someone007 6451 / 4053 / 1598 Регистрация: 09.05.2015 Сообщений: 9,481
	04.06.2016, 23:43	17
	Судя по всему данное ограничение было убрано в C# 6.0: источник. 0