[fpc-devel] Re: Testing for..in feature
klenin at gmail.com
Fri Nov 6 00:42:17 CET 2009
On Fri, Nov 6, 2009 at 05:51, "Vinzent Höfler"
<JeLlyFish.software at gmx.net> wrote:
> Von: Michael Van Canneyt <michael at freepascal.org>:
>> Like I said, we should not have named it enums. They are not enums.
>> They're a hack to support some C construct in a type-safe way.
>> No more, no less.
[skip Ada sample]
> They might be an ugly hack, but I really doubt the part about being a C construct. And then, even in Ada, the definitions have to be in (ascending) order. Which means, the compiler only has to support "holes", not an arbitrary set of values.
> Maybe this would be an option for FPC, too?
I agree that there is, in principle, nothing wrong with sparse enums.
However, Ada is well-known for sacrificing performance for correctness and
generality, and I am not sure if FPC should follow that.
The best Succ(X) algorithm I can think of that works correctly on
sparse enums is O(log enum_size).
>Which means, the compiler only has to support "holes", not an arbitrary set of values.
Yes, current enum implementation in FPC is slightly broken in this aspect:
T = (a = 0, b = 0);
Alexander S. Klenin
More information about the fpc-devel