Maurice Lombardi wrote:
I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here.
But this is much harder to standardize: they will have different meanings on different systems, whence better to reject them in XXcompat units: gpc being cross-platform it will be difficult to give a general rule whereas the others are non ambiguous:
I didn't intend them to be in a XXcompat unit, but rather built-in (the only place they *could* be declared, AFAICS), provided it can be guaranteed on every platform that
- 2 <= SizeOf(ShortInt) < SizeOf(Integer) < SizeOf(LongInt) (or perhaps even 8 <= 4*SizeOf(ShortInt) = 2*SizeOf(Integer) = SizeOf(LongInt) ?)
- SizeOf(LongInt) < SizeOf(LongLongInt) (if LongLongInt is possible) (resp. 2*... = ...)
- SizeOf(LongestInt) is the biggest possible integer size for the given compiler.
(The same, of course, for Card*.)
Types like Short* and Long* can be useful e.g. for multplications (ShortInt * ShortInt always fits in an Integer, Integer * Integer fits in a LongInt, ...).
Longest* would be useful for programs that want to offer the biggest possible range without having to know what this is on every platform.
Furthermore, it *might* become useful to have a Cardinal that's exactly the size of a pointer (since for a normal Cardinal this doesn't always hold, and AFAIK, only the compiler knows the actual pointer size). Though pointer arithmetic has mostly eliminated the need for explicit type casts between pointers and integers, there may be some cases left, where it's needed...
but notice that in BP I frequenly used a defreal unit, (referenced from the main and all other units) which contains either
type real = single or type real = double or type real = extended
to have a quick way to see the effect of the size of reals on accuracy or speed of some computations. But this is a purely private trick which should be restricted to such peculiar purposes.
I think you could do this in gpc as well (I see no reason why not).
PS: No copies by email necessary. I get your mails through the list, anyway.
Peter Gerwinski wrote:
Cardinal 0 .. 2147483647 Non sign=E9, 32 bits
If Delphi uses "Cardinal", gpc should use it too, of course.
It already does. 32 bits, unsigned.
True, fine! :-)
As you can see above, `Cardinal' is 31 bits, unsigned, in Delphiy. Has anybody an idea, why?
I guess they didn't want to get into trouble with the internal handling of integer values in the compiler. If Cardinal is a subset of Integer, they can store anything in an Integer internally. Otherwise, they'd have to have a flag indicating if signed or unsigned (I guess this is what gpc does, right?). IOW: The same reason why there wasn't an unsigned 32 bit integer in BP (I suppose).
GPC's current setting - on *all* platforms - is the following:
GNU Pascal GNU C Byte unsigned char ByteInt signed char
Is a char *always* 1 byte in C?
ShortWord unsigned short ShortInt short Integer int, long Word, Cardinal unsigned, unsigned long LongInt, Comp long long LongWord unsigned long long
How about "ShortCard" and "LongCard", too?
I guess, Comp should rather be fixed to 64 bits ("Integer(64)") than dependent on "long long", for BP compatibility.
Since you didn't mention it, I assume it's not possible (on current platforms) to have an integer > 64 bits, is it?
I see only one possible reason why we should change that: It is not absolutely sure that `int' will always remain the same as `long' on GCC.
Is it guaranteed that "short" is always shorter than (resp. half as big as) "int", and "int" than "long long"?
The sizes of these types are the same on all platforms I have seen so far. (8, 8, 16, 16, 32, 32, 64, 64.)
Also on the Alpha? Isn't this a 64 bit processor (so "int" should be 64 bits)? But anyway, I guess, this can change in the future...
I agree, but maybe a different syntax would be preferable. UCSD Pascal has a "long Integer" type which is written as
Type Int42 = Integer [ 42 ];Where `42' is the number of decimal digits. (In the long run, this should be in GPC, too.) What about defining
Type Int16 = Integer ( 16 ); Type Word16 = Word ( 64 );for types with a specified number of *dual* digits, read: bits?
Why not! (With the actual size rounded up to bytes (or to a power of 2 of bytes) unless in a packed array/record?)
What are we talking about?
Pascal has subrange types. Why not forget about all this and let the user specify the types by himself?
Type I16 = -$8000..$7FFF; W16 = 0..$FFFF;
MyRecordToAccessSomeStrangeSystemData = record Descriptor: 0..$FFFFFFFF; ImportantData: -$80..$7F; FillSpace: array [ 0..42 ] of 0..$FF; end (* MyRecordToAccessSomeStrangeSystemData *);
Then, of course, GPC must not reserve more space than necessary for them - which it does not do anyway since it has packed records.
But it does if you declare the type plainly, i.e. Sizeof(0..$FF) = 4. This is handled faster than one byte, but takes more memory. What about "packed" with those types as well ("type Int8 = packed -$80..$7F")? -- Looks strange, I know, but there should be some way to decide if one wants speed or small size (the latter can be important e.g. in binary files).
Given this or something equivalent (and of course, subranges that exceed Integer), I'd prefer this to "Integer(n)".
The African Chief wrote:
{$ifdef _Borland_16_Bit_}
Is this defined by default in your unit?
No. The definition is commented out (with a dot before the "$")
(Otherwise it might be confusing for BP->gpc programmers.)
BP->GPC programmers (like me) may want BP syntax support, but not necessarily want to use 16-bit data structures instead of the default ones. It is quite easy to remove the dot.
Ok, so by default the unit uses data types like BP, but it can be changed, right? (That's what I meant how it should be for unsuspicious BP->gpc programmers.)
BTW: I just took a look at BPCompat1.0. Just a few quick comments:
- How about some sub-directories (perhaps according to the 5 sections of files in *.txt)? Would help in order to see immediately what's needed for "only" BP compatibility, and what's additional functionality.
- Concerning FindFirst and FindNext in Dos: is there any reason why they're functions, not procedures? Delphi? If so, perhaps dependent on a compiler switch? (Is there a way to test in a program, if "--borland-pascal" or "--delphi" was given?) Otherwise, you'll always get warnings in BP programs (and I don't think it's a good idea to disable warnings globally).
- If you want to use my random functions in System, you're welcome to include them, of course. (Perhaps one day we can claim "100% BP compatibility -- even the random numbers are the same..." ;-). As a preliminary solution for the overloading problem, one could use the (case-sensitive!) preprocessor, as by defining "{$define random RandReal}". Then "random" would be for real types, and all other cases for integers. (Or perhaps vice versa? Or all-caps?) At least, programs could be the same for BP and gpc in this respect. :-)
-
Frank Heckenbach