B
B
BadCats2016-03-08 14:47:27
.NET
BadCats, 2016-03-08 14:47:27

What is the relationship between data types in c#, .net and windows, in the context of using aliases?

Prehistory
Please take a look at the topic I created on another forum (purely to understand the general picture)
www.cyberforum.ru/csharp-beginners/thread1664793.html
I wanted to understand why in c# you can use an alias for any integer data type
(byte, sbyte, short, ushort, int, uint, long, ulong) but can't
use any C# system integer data type (Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64) ?
A full description of this issue has already been given by me on the Toaster:
Aliases (aliases) in enums - usage rules (c#)?
it ended up being a bug that was fixed in C# 6.0, but now I'm trying to figure out what the bug is.
I was given a link on the above forum
https://social.msdn.microsoft.com/Forums/en-US/70b...
and this got me hooked:

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 the
C# language forum.
-Karel

response to the first quote:
"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.

answer to answer:
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 the 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 ﴾eg 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.
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

I need your opinion on these quotes. Thank you all in advance!
I need to find out: is there a grain of sense (sense about the fact that in the IL code these are still different types) in these assumption quotes or is it just nonsense?
They gave this answer:
BadCats, why, you can understand a person. He says that for a programmer, short and Int16 are the same type, but for runtime they are different things. You will never see differences from sharp, because at the language level it is again the same thing (primitive typeof(short) == typeof(Int16) will confirm this), but at lower levels these are different things, because Int16 is a structure into which the "real" number is packed when boxing, and when unboxing, respectively, it gets. Accordingly, since Since method calls (at least through an interface) are impossible without boxing, they can only be called on an "adult" structure. About cases when you can use only a number, but you can’t understand the structure a little - too low-level things are affected.

BUT I have the following question:
what side (quotes in English) does this have to do with the incompatibility (in C# versions younger than 6.0) of aliases and "full-fledged types" in enumerations? In short, the question of this whole topic ( Aliases (aliases) in enums - usage rules (c#)? ), in relation to these answers on MSDN
Who is interested in this topic of confusion when using aliases, here are links to other sources
1) Microsoft's official response to this bug (link to archive with answer saved since original page has been deleted): https://web.archive.org/web/20140310042420/http://...
2) stackoverflow.com/questions/7511102/changing- the-u...
3) http://ru.stackoverflow.com/questions/496085/Pseudo...
4)stackoverflow.com/questions/5005319/why-cant-i-dec...

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
Stanislav Silin, 2016-03-08
@BadCats

What problem do you want to solve?
Int32 is a data type from the .Net runtime, int is a data type from C#. It seems quite logical to me that only C# types can be used in an enum (which is part of C#). Just because C# is built on top of .Net doesn't mean that types should be interchangeable, that's probably a bad thing. Since if the runtime specification changes, the code written in C# will also suffer. And so you can change the runtime as much as you like, but the code will work.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question