[fpc-devel] integer, cardinal

[Marco van de Voort]

> > > That's why Pascal has range types. Define the range you need, and
> > > don't use "just some type" which has the range you think you will
> > > need.
> >
> > I actually tried this in a major app at work.
> 
> Well, and I actually do this in a major app at work. Not on everything, 
> of course, but it can heavily simplify some stuff, for instance because 
> I can use the Low and High-attribu^Wfunctions on the type which is 
> safer than using constants, because the compiler can do the work for 
> me.

I typically use enums. They suffer from the same to-disk problem though,
but that can be remedied using the proper directives.
 
> > However quite a lot of datastructures get written to disc sooner and
> > later, and to get fileformats size independant, you need a lot of
> > datastructure conversions (from records with fields that have arch
> > dependant size to packed records with fields with fixed sized integer
> > types).
> 
> Yes, of course, that's the outside world.

But if you have only business data, nearly everything is directly connected
to it. One only moves the problem (from declaring types fixed size to 
data-spooling). And it is a lot more laborous.

> For instance, I have to read 
> Image-files (and if you know TIFF, you know the beast) and have to 
> write binary structures to a connected embedded system and there I 
> badly need known size types, but that's about it.
> 
> Maybe, you have to do such things more often, but - no offense meant - 
> earlier experience led me to believe that binary file formats are evil. 

Textformats vary with systems too. No solution either. (e.g. encodings,
lineendings and other control characters). And besides that, I'm spooling
millions of objects to disc during startup and shutdown. Cooked I/O is
magnitudes slower. (I work with readers/writers, text-IO output is supported
for debug purposes)

Binary formats are IMHO not evil. It's more that the simple basic rule of
programming applies to it, think things through thoroughly before starting,
and then the best effort deals with the bulk of the problems, and
for the rest make custom solutions if the problems actually arise.
One simply can't tailor to every possibility without making things costly or
usuable.

Some simple things:
- use endian indicators somewhere near the top of the file.
- store size of records.
- use magic numbers to detect possible problems (more a testsuite thing,
	but still a good thing)
- use an alignment supported by a lot of compilers. (packed, C or 4 byte)
- be a bit smart with your types, and don't have too many.

> They tend to change too often, they tend to use types that don't even 
> survive half a decade, and even if this doesn't matter known size types 
> won't save you from the Hell of Endianess. And if you don't have that 
> problem, you don't have it all. ;-)

How do read in EBDIC textfiles btw? And unicode files in some transient
standard?