Re: Something that really annoys me in Delphi ...

From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 01/07/04 

Date: Wed, 7 Jan 2004 22:50:44 +0100

"Nicolai Hansen" <nic@aub.dk> wrote in message
news:d96764ff.0401070627.799788e1@posting.google.com...

>> Delphi could not predict all modifications of your GoAction variable.
>> What about the following example, which is quite valid:
>>
>> GoAction:=gaWrite;
>> ...
>> GoAction:=Succ(GoAction);
>>
>> In this case, your function will have undefined result.

> Interesting... A function that works on enumerations without range
> checking.

Only if you turn it off in the compiler options. The code is
(syntactically) valid, but it will cause a run-time error in
any program of mine. I simply never turn off all the debugging
options.

> This puzzles me. Someone, please again, mention to me that Delphi is
> strongly typed language and this is its main advantage to C.

Pascal is a strongly typed language and this is one of its main
advantages over C.

> Functions like the mentioned should have big red warning signs posted
> all around it "-this method is using unsafe typecasts and might give
> invalid results-" or something like that ;)

Calling Succ is not ordinarily considered to involve any typecasting.
But you're right, it does - in the sense that the compiler apparently
simply emits an INC instruction on the storage for the expression,
which indeed amounts to a cast to, well, perhaps not Integer but DWORD,
and a cast back.

I think this is reasonable. CPUs don't have any fundamental operation
with the same semantics. The semantics are that the function returns
the next higher value in the type's range, if it exists, and is not
defined (and even invalid to call at all) otherwise. But enforcing
the invalidity of calling Succ(High(.)) requires a range check, and
due to technical limitations this means having range checking enabled
globally.

There is a philosophical question here. Is it permissible to call
Succ on a value that has no successor, if one never thereafter evaluates
the return value? If a type rolls over in a forest where there's no-one
to see it, does it make a crash?

Groetjes,
Maarten Wiltink

Relevant Pages

  • Re: problem with memcpy and pointers/arrays confusion - again
    ... this second method is known as an explicit conversion, or cast. ... The cast, in effect, tells the compiler: ... the malloc function. ... function taking a size_t as a parameter and returning a void pointer (i.e. ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... This would violate the division between preprocessor and compiler too ... much (the preprocessor would have to understand quite a lot of C semantics). ... ...This is legal C (as per the Standard), but it overflows the stack on ...
    (comp.lang.c)
  • Re: about the array
    ... 3- If you cast to the wrong type by accident, ... are malloc and free. ... the compiler should issue a diagnostic - gcc ... unknown set of arguments, and return an int. ...
    (comp.lang.c)
  • Re: Can generics really produce strongly typed collections?
    ... The compiler won't detect the bug at compile time. ... will try to cast to B, ... The "foreach" statement specifically behaves in the way you ... interface, assuming one exists. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a case for multiple inheritance
    ... and overrides the write functions to change ... the compiler would optimize it so that the double function call would be ... private new void Foo ... The cast not much ...
    (microsoft.public.dotnet.languages.csharp)