Hello fredvs,
you wrote on Thu, 12 Mar 2020 18:02:03 -0700 (MST):
> > Why could that drive someone crazy, ?
>
> Huh, I was talking about all the possibilities that enum gives and the
> difficult task to choose the best one.
An enum (C-speak) aka enumeration is just that: An enumeration of
identifiers that may be used as selectors for arbitrary things.
In contrast to sets, though, the identifiers have a defined _order_ and
so they may be represented by a sequence of numerals of the same order.
> The "new illegal-nil-none item" in the enum can be placed everywhere but
Yes. Any member can, as long as its position in the sequence is not used.
> imho at end will give shorter code and so less chance to introduce new
> bug.
Not so if there's no use of the position of any member.
(Yes, then it's also possible to use a set.)
> This when code like this is used:
>
> --> for ar1:= low(scrollbarareaty) to high(scrollbarareaty) do begin
_This_ code _does_ make use of the _order_ and the members' positions in
the sequence, thus it _is_ sensitive to the ordering of the members and
_will_ be affected by insertions or removals of members, at least in the
range used.
> // was changed with (due to 2 last added items):
>
> ---> for ar1:= low(scrollbarareaty) to sba_end do begin
If the last 2 members shall not be used here, the modification is required.
The expression "high (scrollbarareaty)" is equvalent to the last member of
the type, and "low (...)" to its first member, of course.
> ________________________________________
>
> And there is also the proposition of Roland that is great:
>
> type
> TOption = (optNil = -1, optOne, optTwo, optThree);
> TValidOption = optOne..optThree;
That's just a use of the (C-derived) extension of enumerations by fpc to
allow "assigned" members, i.e. members given an explicit value.
Preceding members start counting from 0 (there are none above), following
members count on with the next available value.
CAUTION: THERE IS NO PROVISION TO AVOID DUPLICATE VALUES!
But duplicate values will probabely, hopefully, produce a compiler error
or at least a warning.
And there is NO PROVISION TO AVOID HOLES in the sequence of values.
Holes are expressly allowed, even:
TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20);
is perfectly valid, but using it as a counting sequence, e.g. in a "FOR"
statement like this:
FOR we:= low (weird) TO high (weird) DO Write (ord (we), ': ', we);
WILL NOT WORK. It throws a runtime error and aborts the program.
Why? Because the type member sequence IS NOT (numerically) COMPLETE, as
would be required by the "FOR" statement counter. It contains holes, the
counter will try to produce the value of members that simply DO NOT EXIST.
And fails.
> var
> o: TOption;
>
> begin
> o := optNil;
> for o := Low(TValidOption) to High(TValidOption) do
But if done correctly, this will work correctly, of course.
BTW, I'm NOT using the latest development version of fpc, I'm using
"Free Pascal Compiler version 3.0.4 [2020/03/06] for x86_64".
(Recently upgraded from version 2.6.4.)
> _________________
>
> You see, not easy to decide what code to choose.
Welll...
It's even _very_ easy to decide what code to choose:
choose _correct code_! Provably and proven correct code.
Yes, that's not that easily produced, it may even be a lot of work.
As to the use of enumerations, you may play a bit with the following
program, which is, BTW, _not_ fully correct. Find out why and how to make
it behave:
PROGRAM weird;
TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20);
VAR we: weird; wn: integer;
BEGIN
WriteLn ('low: ', low (weird), ', value: ', ord (low (weird)),
'; high: ', high (weird), ', value: ', ord (high (weird)));
FOR wn:= ord (low (weird)) TO ord (high (weird)) DO Write (wn, ' ');
WriteLn;
FOR we:= low (weird) TO high (weird) DO Write (we, ': ', ord (we));
WriteLn;
END.
Have a lot of fun!
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
