Re: types and subtypes, was New Book: The School of Niklaus Wirth

gdemont@my-deja.com schreibt:
>Now you have to decide what to do with an expression like (-i)
>for a "subrange" like 0..100. To convert to a larger range,
>to wrap or to detect a range error ?...


Such behaviour is part of the language specification. Within
expressions, the arguments usually are silently mapped and extended
into the next wider range, possibly into real values if so required.


Range errors can occur only, when a value is assigned to a variable of
an inappropriate type.


> > >A subrange is a thing, the kind of animal containing the value is
> > >another.


Agreed. The definition of subranges does not affect the binary
representation and storage of the according values. Variables only
must have enough bits, to store values of their defined range. IMO a
compiler is free to choose a much larger data type for the storage of
variables, unless other restrictions (external storage, unions...)
imply fixed sizes for well defined data types. In Pascal also the
"packed" keyword imposes such a restriction, indicating that the
compiler really should use the minimum amount of memory for every data
item. I also know of a (Basic) compiler, which uses single bits for
*array members* of Boolean type.




>Maybe it has been redesigned in some version of Delphi - has it ?


I never heard of the mentioned problems with any Delphi compiler. The
compiler also outputs hints, when "combining signed and unsigned
values - extending into next higher range". Such hints usually point
to inappropriate data types of the involved variables, with real
impact on processing speed, like when the non-native Int64 data type
then will be used in the calculations.


Delphi also uses a "classification" byte for every numeric variable,
indicating the minimum amount of bytes, required to store an according
value, and it's "extensibility". The "extensibility" characterizes the
value as floating-point, signed, unsigned or dont-care. Here dont-care
means, in my interpretation, that the sign bit is always zero, so that
the value can be combined directly with both signed and unsigned data
types of the same byte-size, extending the arguments into the next
higher range then is not required.


I only know of a single problem in Delphi, where "shr" always shifts
unsigned, even if the documentation states, that "shr" performs a
division by a power of 2. But AFAIR the "shl" and "shr" operators are
specific Delphi extensions to Pascal, so I suspect that most likely
the description will be changed in a future version, not the behaviour
:-(


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.