为什么没有"日期和QUOT;在C＃的System.DateTime的速记？ [英] Why is there no "date" shorthand of System.DateTime in C#?

问题描述

如 INT ，长， USHORT ， UINT ，短等

为什么ISN ŧ有一个短手的System.DateTime ？

解决方案

许多类型都与C＃的简写相关的关键词;例如， System.Int32 也可以写成 INT 和 System.String 可以写成字符串。为什么没有为的System.DateTime ？

的简写

我之前回答这个问题 - 或者说，不回答这个问题 - 让我们首先注意到了C＃速记的类型。他们是

 对象
串
为sbyte字节的短USHORT INT UINT长ULONG 
字符
布尔
十进制双精度浮点
  

让我先谈谈一些其他的答案。

空军终于曼正确地指出，一些这些关键字来从C; C有 INT 和相当罗嗦 unsigned int类型，双击和其他几个人。然而ç最明显的是不具有布尔，长，小数，对象或字符串。

我觉得我们可以合理地说，一个理由包括关键字 INT 和字符等都是让用户熟悉C和C ++可以在C＃中快速生产。本文的目的是为关键字很熟悉C语言程序员，但它绝对不是目的，这些关键字具有相同的语义，因为他们在C. c执行不指定任何这些的大小，例如，和大力鼓励 INT 是天然大小的机器。 C＃不指定每种类型的确切大小和范围。

因此，我不认为我们可以有理由说，理由的不的有一个简写的System.DateTime 是因为那里没有在C.有没有字符串或十进制用C两种。

贾森指出，的DateTime 不是的部分C＃语言，因此没有一个关键字。但是，这是彻底乞讨的问题！现在的问题本质上是那么好了，那么为什么DateTime的C＃语言的不是一部分？回答的方式的问题需要平等的难度要回答的问题就是所谓乞讨问题，这个问题已经彻底央求道。

有启发要考虑什么是根本的类型。在某种程度上都具有关键字在C＃中的类型是非常特别，的除了小数 的。也就是说，底层的运行库特殊的行为把它建成为对象，很明显，因为它是普遍的基本类型。 字符串可以简单一直是字符数组，但它不是;字符串是特殊的。 （因为它们可以被扣留，它们可以是恒定的，它们可以在元数据中存在的，等等。）的积分和二进制浮点类型都具有内置到对它们的操作的框架特殊处理。

但 System.Decimal 只不过是另一种结构类型;它是整数的128位和很多用户定义的运营商。如果他们想任何人都可以实现自己的小数运算类型。但福 System.Decimal 通过使C＃语言的一部分，意味着即使其转换为方法来实现，我们把他们当作的内置转换的，不作为的用户定义的转换的。

所以小数确实是一个奇怪的。这不是一个基本型运行，但它是一个关键字。

这虽然带来了一个有趣的问题。的 System.IntPtr 的和的 System.UIntPtr 的*为*基本类型的运行时。它们是指针大小整数类型;他们是什么C指 INT 和 unsigned int类型。尽管这些类型的.NET运行时的类型系统的基础，他们做的不的得到祝福与关键字。

因此，我们可以拒绝只有基本的类型得到一个关键字的说法。有，进行了一个关键字的非基本型，并且没有得到一个关键字的基本类型，所以基本类型和种类，进行了一个关键字之间没有一对一的关系

蒂格兰冠瘿碱的选择是历史性的，这是正确的，但实际上并没有回答这个问题。

汉斯帕桑特明确指出，正确的是指定一个int的大小和范围有助于使语言行为，甚至在本地整数大小的变化一致，并指出的DateTime 已经被设计为面向未来。虽然这个分析是正确的，它并不能解释为什么小数由关键字。有没有担心机器的本土小数的大小会在未来发生改变。此外，C＃语言已经指出，尽管双总是会消耗8个字节的存储空间，也没有要求，即C＃限制双打的加工精度仅为64位;其实C＃程序经常做的80个或更多位的双精度运算。

我不觉得回答这些问题的成功解决的问题。因此，让我们回到正题：

许多类型都与C＃的简写相关的关键词;例如， System.Int32 也可以写成 INT 和 System.String 可以写成字符串。为什么没有为的System.DateTime ？

答案速记这个问题是一样的答案形式的每一个问题，为什么C＃没有实现一个功能，我想？答案是：我们并不需要提供不执行功能的理由功能是的昂贵的，并且，雷蒙德陈经常指出的那样，是的未实现。默认情况下的。 。它没有工作，留下一个未实现的功能未实现

该功能的建议是没有的不合理的根本; Visual Basic中在某种意义上对待的DateTime 作为一种特殊类型，C＃可能太多，如果我们决定，这是值得做的工作。但不是每一个合理的功能得到实施。

Such as int, long, ushort, uint, short, etc.

Why isn't there a short hand for System.DateTime?

解决方案

Many types are associated with "shorthand" keywords in C#; for example, System.Int32 can also be written int and System.String can be written string. Why isn't there a shorthand for System.DateTime?

Before I answer that question -- or rather, fail to answer it -- let's first note the types that have shorthands in C#. They are

object 
string 
sbyte byte short ushort int uint long ulong 
char 
bool 
decimal double float

Let me first address some of the other answers.

Mystere Man notes correctly that several of these keywords come from C; C has int and the rather wordy unsigned int, double, and a few others. However C most notably does not have bool, long, decimal, object or string.

I think we can reasonably say that one justification for including keywords int and char and so on is so that users familiar with C and C++ can be productive quickly in C#. The aim here is for the keywords to be familiar to C programmers, but it was absolutely not the aim for these keywords to have the same semantics as they do in C. C does not specify the size of any of those, for example, and strongly encourages int to be the "natural size" of the machine. C# does specify the exact size and range of each type.

So I do not think we can reasonably say that the justification for not having a shorthand for System.DateTime is because there was none in C. There was no string or decimal in C either.

Jason notes that DateTime is not "part of the C# language" and therefore does not have a keyword. But that is thoroughly begging the question! The question is essentially then "OK, so then why is DateTime not a part of the C# language?" Answering a question in a manner which requires a question of equal difficulty to be answered is called "begging the question", and this question has been thoroughly begged.

It is instructive to consider what are the "fundamental" types. All of the types that have keywords in C# are "very special" in some way, except for decimal. That is, the underlying runtime has special behaviour built into it for object, obviously, as it is the universal base type. string could have simply been an array of char, but it is not; strings are special. (Because they can be interned, they can be constant, they can exist in metadata, and so on.) The integral and binary floating point types all have special handling built into the framework for their operations.

But System.Decimal is just another struct type; it's 128 bits of integers and a whole lot of user-defined operators. Anyone could implement their own decimal arithmetic type if they wanted to. But "blessing" System.Decimal by making it a part of the C# language means that even though its conversions are implemented as methods, we treat them as built in conversions, not as user-defined conversions.

So decimal really is an odd one. It is not a "fundamental" type of the runtime, but it is a keyword.

This brings up an interesting point though. System.IntPtr and System.UIntPtr *are* fundamental types of the runtime. They are the "pointer sized integer" types; they are what C means by int and unsigned int. Even though these types are fundamental to the .NET runtime's type system, they do not get blessed with a keyword.

Thus, we can reject the argument that only "fundamental" types get a keyword. There is a non-fundamental type that got a keyword, and a fundamental type that did not get a keyword, so there is no one-to-one relationship between fundamental types and types that got a keyword.

Tigran opines that the choices were "historical", which is correct but does not actually answer the question.

Hans Passant notes correctly that clearly specifying the size and range of an int helps make the language behaviour consistent even as the native integer size changes, and notes that DateTime has already been designed to be "future proof". Though this analysis is correct, it does not explain why decimal is made a keyword. There's no fear that the "native decimal size" of a machine is going to change in the future. Moreover, the C# language already notes that though a double will always consume 8 bytes of storage, there is no requirement that C# restrict the processing of doubles to a mere 64 bits of precision; in fact C# programs often do double arithmetic in 80 or more bits of precision.

I don't think any of these answers successfully address the question. So let's return to the question:

Many types are associated with "shorthand" keywords in C#; for example, System.Int32 can also be written int and System.String can be written string. Why isn't there a shorthand for System.DateTime?

The answer to this question is the same as the answer to every question of the form "why does C# not implement a feature I like?" The answer is: we are not required to provide a justification for not implementing a feature. Features are expensive, and, as Raymond Chen often points out, are unimplemented by default. It takes no work to leave an unimplemented feature unimplemented.

The feature suggestion is not unreasonable at all; Visual Basic in some sense treats DateTime as a special type, and C# could too if we decided that it was worthwhile doing that work. But not every reasonable feature gets implemented.

这篇关于为什么没有"日期和QUOT;在C＃的System.DateTime的速记？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！