Gpc April 2000

gpc@gnu.de

22 participants
44 discussions

Using a unit as a record name...
by Orlando Llanes 06 Apr '00

06 Apr '00

I don't know what else to call the subject, but here's a fragment of code that will show what I want to do: type TEDFileIO = object Handle : File; destructor Close; virtual; end; destructor TEDFileIO.Close; begin System.Close(Handle); end; I'm having slight trouble compiling the latest version (I just started to use Linux on a regular basis). The last binary version of GPC did not allow me to do this. If the above does not work, is there a way around it in which I would not have to change the name of the method? See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 1

Re: Byte Order checking without {$ifdef}'s...
by Frank Heckenbach 06 Apr '00

06 Apr '00

Marco van de Voort wrote: > > The above code should compile, I translated it from the BP code. The > > only difference is in the type declarations; mByteOrder must always be > > 32-bits, and mByte must always be an array of 4 elements with 8-bits each, > > hence the use of Cardinal(x). > > The way it works is simple, and the code does not depend on any > > compiler specific syntax (except for type declarations) so it should > > compile correctly in the long run. AFAIK, constants are compiled in the > > native byte order of the target architecture. By comparing the long value > > as bytes, one-by-one, the byte order can be determined, hence the > > endianess can also be determined. > > I have tested this code on a Macintosh computer (which is the only > > big-endian machine I currently have access to), and have of course tested > > this on a PC. The results displayed are correct in both architectures. > > This is very nice, but will require runtime testing (and checking of the bigendian > flag *each* time) True. Of course, you could do the test once per program and save the result in a static variable, but still I don't quite see the need for runtime endianness checking... > Maybe it is smarter to let the above program output something to an includefile. > > The makefile should then always compile the above program prior to the actual > compilation. > > This way one would have the flexibility AND the compiletime decision between > little and big endian? This would make the build process more complicated and, worse, wouldn't work at all for cross-compiles where you usually can't run a program on the target machine (Linux->Dos with DosEmu perhaps being an exception ;-). But fortunately this isn't necessary because GPC also provides the information, both as pre-defines and as constants -- look for `endianness' in gpc.pas. I'd recommend to use the constants when possible and the defines only when necessary (e.g., when type declarations depend on them) because `ifdef' etc. is generally unsafer (e.g., you won't even detect syntax errors in the version of the code not for your current working system). BTW, that's also how I wrote the endian conversion routines, to answer Orlando's question. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Byte Order checking without {$ifdef}'s...
by Orlando Llanes 05 Apr '00

05 Apr '00

This is something that is prolly considered "common-sense" but I'm posting anyway just in case someone can benefit from it. I might've gotten the idea from Frank's code posted a while back, I don't remember how he implemented Endian conversion routines. Here's the code: program Test_Endian; const ByteOrder = $01020304; function LittleEndianCPU: Boolean; var mByteOrder : Cardinal(32); mByte : array[ 1..4 ] of Cardinal(8); begin mByteOrder := ByteOrder; Move(mByteOrder, mByte, 4); LittleEndianCPU := (mByte[1] = 4) and (mByte[2] = 3) and (mByte[3] = 2) and (mByte[4] = 1); end; function BigEndianCPU: Boolean; var mByteOrder : Cardinal(32); mByte : array[ 1..4 ] of Cardinal(8); begin mByteOrder := ByteOrder; Move(mByteOrder, mByte, 4); BigEndianCPU := (mByte[1] = 1) and (mByte[2] = 2) and (mByte[3] = 3) and (mByte[4] = 4); end; begin WriteLn( 'Little Endian CPU present -> ', LittleEndianCPU ); WriteLn( ' Big Endian CPU present -> ', BigEndianCPU ); end. The above code should compile, I translated it from the BP code. The only difference is in the type declarations; mByteOrder must always be 32-bits, and mByte must always be an array of 4 elements with 8-bits each, hence the use of Cardinal(x). The way it works is simple, and the code does not depend on any compiler specific syntax (except for type declarations) so it should compile correctly in the long run. AFAIK, constants are compiled in the native byte order of the target architecture. By comparing the long value as bytes, one-by-one, the byte order can be determined, hence the endianess can also be determined. I have tested this code on a Macintosh computer (which is the only big-endian machine I currently have access to), and have of course tested this on a PC. The results displayed are correct in both architectures. See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 2

Re: 6 MOD -90 Problem on Windows
by Frank Heckenbach 05 Apr '00

05 Apr '00

Tim Kaulmann wrote: > I found out that the result of 6 MOD -90 in my little Pascal Program on > Windows is -84 and on Solaris is 6 (in my opinion the right one). > Whats up there ? > BTW : My Calculator HP48 says that -84 was right ??? > A matter of definition ? Actually, it's defined as an error when the right operand is <=0. So probably we should implement such a check in GPC (perhaps together with other kinds of range or overflow checking). If in your program the right operand is a variabls which might be negative, I suggest to use `Abs' (i.e., `a mod Abs (b)'), since a mod b = a mod (-b), according to "your" definition. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc April 2000