On Fri, Nov 6, 2009 at 05:51, "Vinzent Höfler" <jellyfish.softw...@gmx.net> wrote: > Von: Michael Van Canneyt <mich...@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. > > IBTD.
[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: --- type T = (a = 0, b = 0); begin Writeln(b); end. --- Prints 'a'. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
