为什么没有非整数枚举?
为什么不能创建非整数枚举? 我想知道这是否 是语言设计决策,或者在编译器中实现此决策是否存在问题。
换句话说,在语言中实现非整数枚举是否可行,但只是没有合理的需求? 或者,如果它不可行但合理,那么有什么障碍?
请有人告诉我 C# 中没有此功能的原因或基本原理,非常感谢。
Why is it that non-integral enums cannot be created? I want to know if this
is a language design decision, or if there are issues with implementing this in the compiler.
In other words, is it feasible to implement non-integral enums into the language, but there just isn't a justifiable need? Or if it isn't feasible but is justifiable, what impediment are in the way?
Someone give me the skinny on what the reason or rationale is for not having this available in C#, pretty please.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
没有技术原因无法做到这一点,但是,我们实际上更多地讨论一组常量(也许在公共名称空间内,如果它们相关的话)。
在枚举中,数值通常是次要的。
下面:
我们仅描述一组命名常量。 我们说的是 Fruit 类型的变量可以采用这四个值之一。 每个整数值是多少,实际上并不相关。 只要我只用名称来引用它们,代表 Apple 的值是 0、1、32、-53 还是 0.002534f 都没关系。
大多数语言确实允许您指定代表每个语言的值,但这实际上是次要的。 它有时很有用,但它不是枚举核心目的的一部分。 它们只是为您提供一组相关的命名常量,而无需为每个常量指定整数 ID。
此外,枚举通常用于指定可以与按位运算组合的可选标志。 如果每个值都由整数表示(那么您只需选择一个使用所需位模式的整数),那么实现起来很简单。
浮点值在这种情况下没有用处。 (按位和/或运算对浮点值没有多大意义)
There's no technical reason why it couldn't be done, but then, we are really more talking about a set of constants (perhaps within a common namespace, if they're related).
In an enum, the numerical value is generally secondary.
In the following:
we are only describing a set of named constants. We are saying that a variable of type Fruit can take one of these four values. What the integer value of each one is, is really not relevant. As long as I only refer to them by name, it doesn't matter if the value representing Apple is 0, 1, 32, -53 or 0.002534f.
Most languages do allow you to specify the value that should represent each, but that's really secondary. It's sometimes useful, but it's not part of the core purpose with enums. They are simply there to give you a set of related named constants without having to specify an integer ID for each.
Further, enums are often used to specify optional flags that can be combined with bitwise operations. That is trivial to implement if each value is represented by an integer (then you just have to pick an integer that uses the bit pattern you want).
Floating-point values wouldn't be useful in this context. (bit-wise and/or operations don't make much sense on floating-point values)
我认为枚举是这样创建的,因为与您想要做的相反,枚举并不意味着保存任何有意义的数字表示。
例如,枚举非常适合描述 ff:(
诚然,颜色可以用复杂的类型在数字上表示,但暂时请允许我)。 心情怎么样?
或味道?
我认为你说对了。 底线是:枚举旨在表示难以用数字表示的对象或对象特征,或者没有有意义或实用的数字表示——因此可以任意分配给整数,这是最方便的数据类型。
这与假期之类的东西相反,假期在数字上是有意义的。
I think enums were made this way because, as opposed to what you want to do, enumerations weren't meant to hold any meaningful numerical representation.
For example, enums are perfect for describing the ff:
(admittedly color can be represented by complex types numerically, but indulge me for the moment). How about mood?
or taste?
I think you get the point. Bottomline is: enumerations were meant to represent objects or object characteristics that are difficult to represent numerically, or do not have meaningful or practical numerical representations -- and thus the arbitrary assignment to an integer which is the most convenient data type for such.
This is as opposed to things like holidays, which are numerically meaningful.
只有该语言的设计者才能告诉您为什么他们不允许非整数枚举,但我可以告诉您最可能的解释。
最初的 C 没有这样做,因为它对于其目的(一种系统编程语言)来说是不必要的。 C++ 没有这样做,因为它是基于 C 的,而且无论如何你都可以用类来模拟它。 出于同样的原因,C# 可能不会这样做。
这只是我的猜测,因为我没有参与任何这些语言的设计。
一旦您决定走课程 (DateTime) 的道路,就没有理由不走到底。 如果要使用枚举,可以将枚举创建为从零开始的连续整数,并使用这些枚举作为索引来创建 DateTime 值数组。
但我只有一个 Holiday 类,它提供了类中的整个工具包和 kaboodle:常量、基于这些常量返回 DateTime 的 get() 例程等等。
这为您提供了真正的封装,并且能够在不影响接口的情况下完全改变实现。 为什么要放弃 OOP 的好处之一呢?
Only the designers of the language can tell you why they didn't allow for non-integral enumerations but I can tell you the most likely explanation.
The original C didn't do it because it was unnecessary for its purposes (a systems programming language). C++ didn't do it since it was based on C and you could emulate it with classes anyway. C# probably doesn't do it for the same reasons.
This is just guesswork on my part since I wasn't involved in the design of any of those languages.
Once you've decided to go the way of classes (DateTime), there's little reason to not go all the way. If you want to use enum's, you can create the enums as sequential integers starting with zero and have an array of DateTime values using those enums as indexes.
But I'd just have a Holiday class which provided the whole kit and kaboodle within the class: the constants, the get() routine to return a DateTime based on those constants and so on.
That gives you true encapsulation and the ability to chage the implementation totally without affecting the interface. Why toss away one of the benefits of OOP?
在不知道实际答案的情况下,我建议更多的是后者——没有真正合理的需要。
在我看来,枚举只是代表特定情况下可用的各种选项; 不实际存储数据。
保存枚举值的变量不应被视为保存值 1、2 或 3,即使这些是存储在该内存位置中的实际值。 它应该被认为代表星期一、星期二或星期三(例如)。 它仅在枚举方面有意义,实际上不应该(尽管经常)以其他方式使用。 您对枚举值执行的操作只是通过实现枚举的方式提供的编程快捷方式。
Without knowing the actual answer, I'd suggest that it's more the latter - there's no real justifiable need.
Enums in my mind are simply there to represent the various options available in a particular case; not to actually store data.
A variable holding an enum value shouldn't be thought of as holding the value 1 or 2 or 3, even if those are the actual values stored in that memory location. It should be thought of as representing Monday, Tuesday or Wednesday (for example) instead. It only has meaning in terms of that enumeration and really shouldn't (although often does) be used in other ways. Operations you perform on Enum values are simply programming shortcuts made available by the way Enums have been implemented.