[fpc-devel] WTF? Type checking dependent on compilation mode!?

Vinzent Hoefler JeLlyFish.software at gmx.net
Mon Apr 25 15:26:19 CEST 2005

On Monday 25 April 2005 12:10, Florian Klaempfl wrote:

> Vinzent Hoefler wrote:
> >
> > consider this piece of code:
> >
> > -- 8< -- snip --
> > type
> >    tA = array[0 .. 5] of byte;
> >    tB = array[0 .. 5] of byte;
> >
> > var
> >    A : tA;
> >    B : tB;
> >
> > begin
> >    FillChar (A, SizeOf (A), 0);
> >
> >    B := A;     // <-- should by type error!
> >    A := tA(B);
> > end.
> > -- 8< -- snip --
> It's simply a thing to make life easier especially for beginners.

Well, maybe my opinion doesn't count too much (because I am an 
Ada-zealot where even integer types are not necessarily 
type-compatible), but IMO _especially_ beginners should be taught about 
the virtues of strong typing.

> I
> don't know a real reason why the arrays shouldn't be considered equal

Maybe because they are used to denote completely different things? To 
show you the definitions from the actual code:

|   tCorr_Table = packed array[byte] of Interfaces.Unsigned_8;
|   tGrad_Table = packed array[byte] of Interfaces.Unsigned_8;
|   tTimer_Ramp = packed array[byte] of Interfaces.Unsigned_16;

tCorr_Table is an array which is used to "linearize" a DAC output, while 
Grad_Table is simply a lookup for byte values to be used (call it 
translation table if you like). Both are applied to different DACs and 
in fact - they are completely different things and that's why I used 
different type declarations.

Types are most often abstractions of real world things, which you simply 
don't want to intermix.

Unfortunately I needed both inside a routine and swapped them in the 
procedure call (it doesn't matter that this time I did it on purpose to 
see if the compiler complains - that's why I detected this).

Oh and BTW, a few months ago

|   tTd_Ramp = array[0 .. 1023] of Interfaces.Unsigned_16;

was "structural identical" with the thing called tTimer_Ramp. And 
although it still does the same thing as before, it is now not "type 
compatible" anymore (what it should have never been IMO). Nothing has 
changed but the type declaration. 

I mean, I don't use types "just for fun". I use them for two reasons: 
One: To make the meaning of things more clear and
Two: to protect me against my own stupidity with the help of the 

> so fpc doesn't complain either ;)

Well, so why does it complain on record types that are "structurally 
identical"? To quote you slightly modified: "I don't know a real reason 
why the structures shouldn't be considered equal".

In the end it's quite simple: If I don't want the types to be different 
I don't declare them that way.

So what's your suggestion? To use $MODE DELPHI instead of $MODE OBJFPC 
if I need exceptions, too?


More information about the fpc-devel mailing list