On 13.07.2019 14:32, Michael Van Canneyt wrote:
I yesterday checked a database project I have. I counted 25 enumerateds
which are stored in the database. Without fail, for each type there is
somewhere code in a type helper:
if (MyDatabaseValue>=0) and (MyDatabaseValue<=Ord(High(TMyENum))) then
MyENumValue:=TEnum(MyDatabaseValue))
else
EConvertError.Create('Invalid value for TMyEnum : %d',[MyDatabaseValue])
I do exactly the same - check the low/high bounds in a type helper :)
Yes, and I am tired of typing it as well :)
That the case where you would write
if MyEnumValue is TMyEnumValue then
can 'by default' be optimized away because as far as the compiler is
concerned this is a tautology, is for me a perfectly acceptable and
defendable point of view.
I agree.
Even to such a degree that the compiler would
simply reject your code by not allowing is/at on a variable of the type
itself. Also defendable.
No - not this one. Don't forget about e.g. generics:
function Test<T>(MyValue: T): Boolean;
begin
Result := MyValue is TMyEnum;
end;
would compile for all enumeration types but not for MyValue:TMyEnum.
That doesn't make sense.
Better to have a compiler hint/warning when such a construct is found
and optimized. This perfectly corresponds with the fact that also
constructs like "SmallIntValue is Integer" can be optimized away but
must be allowed.
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
