- Gpc - gnu.de

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Frank Heckenbach 11 May '98

11 May '98

Andreas Prucha wrote: > I wrote: > >You asked if there is an description of Delphi/OP. I think there is an > helpfile > >available on www.interprise.com (I'll look if I can find it). > > And here you get it: > > ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Thanks, I've fetched a copy. BTW, does anybody know a utility to convert this .hlp file into something "readable" (i.e. some standard format)? -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Achim Kalwa 11 May '98

11 May '98

Frank Heckenbach wrote: > > Is there a way to get the exception that was caught into a > variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); > Frank, your "fantasy" syntax is right. In Delphi: try { do something that might raise an exception } except on Foo : Exception DO ShowMessage(Foo.Message) end Where "Foo" is an instance of the Exception class. There is no need to declare "Foo" as a variable first. Achim

1 0

Delphi properties (was Reformatted: EFLIB as class library for O
by The African Chief (Dr A Olowofoyeku) 10 May '98

10 May '98

Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote; >Thanks Andreas, Chief and the others for your explanations. >I've copied your message's IDs into the To-Do-List so that I and >others can easily find the messages when it's time to implement >these fatures. >I've got a few little questions left (for now :-): >Concerning properties: I assume you cannot pass property fields as >var parameters, right? Correct. If you try it, you get a "Constant object cannot be passed as var parameter" error message. However, you can pass a property as a value and "Const" parameter. >> try >> // code U try to execute >> except >> On EMyException do xxxx; // Do special exception handling here >>On EAnotherException do xxxx; // What you want else raise; // let > > the standard exception handler do the thing > >end; > >Is there a way to get the exception that was caught into a >variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); I have no idea. I don't use exceptions at all. >> And can for type-conversion easyly >> typecased with PChar: >> >> Procedure MyProc (xxx: PChar); > > > >var mystring: String; > > > >MyProc (PChar(MyString)); > >The most recent GPC versions can do this, but without the explicit >type cast, like "MyProc (MyString);". The explicit type cast gives a >warning, and not the intended result. Should GPC learn such type >casts between values of different string types, too? (Peter?) (Since >it seems to be necessary for Delphi compatibility, I suppose the >answer will be yes.) It will be good if GPC will accept the explicit type cast as well as do the implicit one. But note that this should only be done with long strings (at least, that is what Delphi does). With short strings, people should do their own conversion (I think - is there any reason why this should be supported with short strings other than to make life easier for programmers?). Best regards, The Chief ----------------------- Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v4.25 for Win16 and Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

1 0

Re: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Frank Heckenbach 10 May '98

10 May '98

Thanks Andreas, Chief and the others for your explanations. I've copied your message's IDs into the To-Do-List so that I and others can easily find the messages when it's time to implement these fatures. I've got a few little questions left (for now :-): Concerning properties: I assume you cannot pass property fields as var parameters, right? (Otherwise, this would greatly complicate the var parameter mechanism, even in programs that don't use properties at all.) > try > // code U try to execute > except > On EMyException do xxxx; // Do special exception handling here > On EAnotherException do xxxx; // What you want > else raise; // let the standard exception handler do the thing > end; Is there a way to get the exception that was caught into a variable or so? Something like (fantasy syntax): On Foo : EAnotherException do Something.With (Foo.ErrDevice); > And yes. Delphi's implementation is /great/ even the new referece counted > string types make live much easier. They can save more than > 255, This, of course, is true for GPC's strings, too. :-) > are dynamically allocated and referece-counted. Dynamical strings are not yet implemented, but are planned, anyway, in GPC (though they don't seem to be exactly the same as in Delphi). > And can for type-conversion easyly > typecased with PChar: > > Procedure MyProc (xxx: PChar); > > var mystring: String; > > MyProc (PChar(MyString)); The most recent GPC versions can do this, but without the explicit type cast, like "MyProc (MyString);". The explicit type cast gives a warning, and not the intended result. Should GPC learn such type casts between values of different string types, too? (Peter?) (Since it seems to be necessary for Delphi compatibility, I suppose the answer will be yes.) > - Interfaces (not really necessary but nice) Yes, we planned interfaces, too. (I know them from Java and from the OOE draft, I suppose they're similar in Delphi, are they?) However, the internals turned out to be quite difficult. So if someone knows about the internals of how Delphi handles interfaces, especially how it builds the VMTs of classes that inherit from/implement multiple interfaces, any information is welcome! > You asked if there is an description of Delphi/OP. I think there is an helpfile > available on www.interprise.com (I'll look if I can find it). But I doubt that > it is possible to implement it compatible w/o having a look at Delphi itself. > But I hope that I could explain some basic things. This might be useful for a "clean-room reimplementation"... Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Andreas Prucha [helicon] 09 May '98

09 May '98

Hi, I wrote: >You asked if there is an description of Delphi/OP. I think there is an helpfile >available on www.interprise.com (I'll look if I can find it). And here you get it: ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Andreas

1 0

Re[3]: troubles compiling gpc
by Peter Gerwinski 09 May '98

09 May '98

According to Paul Doerwald: > > I changed char *version_string = "2.8.0", compiled, and everything works > nicely now. [...] :-) > Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/specs > gpc driver version 980420(2.8.0) executing gpc version 2.8.0 > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Di586 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -D__i586__ -Asystem(unix) -Acpu(i386) -Amachine(i386) hello.pas /tmp/cca08525.i > GNU CPP version 980420(2.8.0) (i386 GNU/Linux with ELF) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/i586-pc-linux-gnulibc1/include > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/include > /usr/include > End of search list. > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc1 /tmp/cca08525.i -quiet -dumpbase hello.pas -version -famtmpfile=hello.gpc -o /tmp/cca08525.s > GNU Pascal version 980420(2.8.0) (i586-pc-linux-gnulibc1) compiled by GNU C version 2.8.0. > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: invalid #line > /tmp/cca08525.i:2: warning: missing program header > /tmp/cca08525.i:2: parse error at null character I cannot locate the problem from this. Since you reported that everything works now with the "version_string" change, I suspect that the problem leading to this was fixed somewhere after gpc-980420. Well, we will see after the next alpha release. > What I did was change 5987 to TREE_OPERAND (target), and when bison > complained, I changed it *back* to TREE_OPERAND (target,1), and everything > worked. ?? Now I understand: You had a correct version of `parse.y', but a wrong one of `parse.c'. After your changes, bison updated `parse.c', and everything was fine. :-) > Thank you, though, for helping me get gpc to compile. Now I can actually do > some programming (now that summer is here and school is over, and I have > *time* to program! :-) You lucky one! ;-) If you are ambitious, what about porting CRT to Linux? Many people would appreciate that. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

troubles compiling gpc
by Paul Doerwald 09 May '98

09 May '98

This seems an unlikely problem, but I'm actually confounded by it: I can't compile GPC. I've tried a number of different combinations, and it always fails with an abort, a core dump, and an Error 2 on rts-base.p. If I run the xgpc I have on a hello world program, it fails with a core dump. I'd tell you about what version this happened on, but as ftp logs to agnes.dida... will reveal, I have downloaded and tried countless combinations including: gcc 2.8.1 with gpc 980501 gcc 2.8.0 with gpc 980501 gcc 2.8.0 with gpc 980401, and then diffed with 980405 I also downloaded the binary for 980420, and even that came back with numerous errors on a hello-world compile. I'm running a plain Red Hat Linux 5.0 system (glibc2?) on a 486-DX50. The binary for 980420 came in a package with i586 in it, but I don't imagine that should make any difference... I've followed the instructions in the readme in /gnu-pascal/alpha on agnes, but it constantly fails. Here's the errors for a hello world program using the binary for 980420: pollux:~>gpc hello.pas /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: invalid #line /tmp/cca08381.i:2: warning: missing program header /tmp/cca08381.i:2: parse error at null character The source for the program: program hello; begin writeln ('hello, world!'); end. I don't see a problem... The error I'm getting with 980405 and 2.8.0 is this: make[1]: Entering directory `/usr/src/gcc-2.8.0/p/rts' ../..xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/src/gcc-2.8.0/p/rts/../.. -I/usr/src/gcc-2.8.0/p/rts/../../config rts-base.p make[1]: *** [rts-base.o] Aborted (core dumped) make[1]: leaving directory `/usr/src/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 This happens all the time. Once, the compile failed on parse.y, complaining about too many parameters in a function that ended up not existing on either line pointed to by the compiler, but about 10 lines lower down. I changed it, changed it back, and compiled, and it worked... ??? I have in the past successfully compiled gpc-2.0 on a RedHat Linux 4.1 machine Thanks for your help! At this point, I'd be happy with a working binary for my machine attached to a message (compiling on a 486 is SLOOOOW!) | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | Exodus 15:2b

2 1

Re: [rainer] Re: GPC for LINUX
by FPL 09 May '98

09 May '98

Peter wrote > sqr(BTW), right now I am porting a project of 150000 lines from > BP to GPC - not by just recompiling, but it makes progress as > expected. Gee! What is it about? 150000 pascal source code? Also, the rhide url and the old GPC info moping about the lack of borland pascal likewise IDE make me ask this question: what's better than emacs, using pascal mode, for writting pascal? Don't you think Borland ide is just ugly, unusable, unefficient, vomitting? Never understood why you made such a mess about it. Also, the assign example given by rainer seems not to be the better one. When I started using GPC, it was not provided, but one could find a (working) substitutes given in the info. IMHO, the actual problem of using GPC for a user who is not maintening and trakcing the GPC bugs is that he is so sure all his problem are coming from the compiler and not from himself or his debugger! AFAIK, there is no one bug of mine I haven't made GPC responsible for it. It eventually appears that it is never GPC but either gdb or the user who is wrong, but one can't go through his human nature (my experience learnt me GPC is in fact much more reliable that one could expect from a beta version, so with time the effect is dissipating slowly). F.P.L

2 1

Re: Another more striking example
by Peter Gerwinski 08 May '98

08 May '98

According to FPL: > > I think this program is a better example of what the problem is. > It is not as artificial as the prior one, and can be executed > without gdb so that one can see the problem may lie somewhere else that > in debugging informations. > > program loop2(input, output); > var > i, j : integer; > > begin > j:=0; > repeat > for i:=0 to 10 do > if (i div 2)=0 then > begin > write('*'); > j:=j+1; > end; > writeln; > until j=10; > end. > > Do you agree the output should be a rectangular array of 5 stars by ten, No. For each run of the `repeat' loop, only one star (for i = 0) is printed. Perhaps you mean `if i mod 2 = 0'? > Well, what *I* get when running the output code is ... correct. ;-) > Also, I have (in the other program) some file of text type ever opened, > and I have noticed in applying your advice that GPC complains it cannot > write on the default output device (the screen) because of my opened > file. Just a writeln('*') and *not* a writeln(f, '*') wille make it say > > ?GPC runtime error: File is not open for writing (#9) This sounds strange and *maybe* indicates a bug. How did you open the file? The following should work: Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile ); Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

2 4

Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Andreas Prucha [helicon] 08 May '98

08 May '98

Hi, >- Properties: I have them listed in my To-Do-list > (http://fjf.gnu.de/gpc-todo_toc.html) but I personally don't know > too much about them. Are they a Delphi extension? If so, are there > any documents available to describe them, or otherwise, could some > Delphi user put together a list of features required that could be > used as a "standard" that GPC, and perhaps FPK, can implement? Well, they look like fields, feel like fields, but aren't fields. Properties are declared: Property <name> : <type> read <howtoget> write <howtoset>; Proprties can read/write directly to a field or use get/set methods: Type TMyClass = Class (TObject) private FValue : Integer; public property Value : Integer Read FValue Write FValue; end; using the object it can easily be accessed like a field: MyObject.Value := 256; x := MyObject.Value; Data is still encapsuated. It's easy to change the implementation. Let's assume that Value may not be > 255. Type TMyClass = Class (TObject) private FValue : Integer; Procedure SetValue (Value: Integer); public property Value : Integer Read FValue Write SetValue; end; Procedure TMyClass.SetValue (Value: Integer); begin If Value > 255 then Raise Exception.Create ('Value may not be > 255'); FValue := Value; end; If the user now does MyObject.Value := 256; the assignment will fail with an exception. >- Classes: At http://pascal-central.com/OOE-stds.html, there is a > draft for an ANSI Object Pascal standard. AFAIH, Delphi's > implementation is quite close to this standard. One of the plans > for GPC is to implement this standard draft without dropping the > BP object model that is already implemented, in the hope that > there won't be great conflicts between the two. They are quite close. The look the same at the first glance, but they are not compatible. For example, Delphi does not know Class-/Kinds/. Classes are always declared the same way: TNewClass = Class (TDerivedFrom); Encapsulation is done quite the same way as in BP: TNewClass = Class (TObject) private // May not be accessed from outside (also not in subclasses) protected // May not be accessed from outside, but subclasses cann access public // May be accessed from outside published // A IDE-thing. should be handled the same way as "public" end; Othere than the Ansi-Draft in Delphi not each method is virtual. Delphi supports "Virtual" and "Dynamic". Procedure x; Virtual; Procedure y; Dynamic; "override" is used to override the method; Procedure x; override; Create is the standard-constructor and destroy the standard-destructor. Objects are always on heap and the pointer is automatically dereferenced. Objects are initialized the following way: MyObject := TMyClass.Create; and freed with MyObject.Free; Since they are automatically dereferenced it is not necessary to say MyObject^.Free; One of Delphis's bith strengths are the runtime-type-informations. Delphi introduces "is" and "as". "is" checks wheter the object is this or an subclass: If TMyObject is TMyClass then do ...; If TMyObject is a object with type TMyClass or a object of a subclass of TMyClass then the expression is true. "as" is used for typeconversion: try x := (MyObject as TMyClass).Value; except x := 0; end; If the typeconversion to MyClass is not possible (not (MyObject is TMyClass)) as raises an exception. There is much more to say about Delphis Class-Model, but these are the basics. In Delphi both models live together. The old model can be still used, but it is not possible to use the new model to subclass from an old-model-type object. But this is not necessary since in Delphi each class uses the new model. >- Exception handling: I myself would like to use it (for OOP as well > as non-OOP programs), so I'd be willing to put some effort into > implementing it when I have the time (later this year, hopefully). > However, as with properties, I'm lacking a (pseudo-)standard. > I do know the Java exception handling, and I think it's not too bad > and could be implemented similarly in Pascal. OTOH, I read that the > latest GCC version (on which GPC is based) has introduced exception > handling, so it might be easier to implement this if we can reuse Exception handling - really nice thing in Delphi. An exception is fired with raise. The information about the exception is stored in an object. The basic-exception-class is "Exception" raise Exception.Create ('This was wrong'); To use store additional data (e.g. and errorcode) exception can be easily subclassed: EMyException = Class (exception) private FErrorCode: Integer; public Constructor Create (Errorcode: Integer); property Errorcode : Integer Read FErrorcode; end; Constructor EMyException.Create (Errorcode: Integer); begin FErrorCode := Errorcode; Inherited Create ('Error '+IntToStr(Errorcode)); end; Exceptions are catched the following way: try // code U try to execute except // handle the exception end; Since exceptions are classes the different types of exceptions can be handled in "except" try // code U try to execute except On EMyException do xxxx; // Do special exception handling here On EAnotherException do xxxx; // What you want else raise; // let the standard exception handler do the thing end; "finally" is used to assure that some piece of code is always executed: try // code U want to execute finally // Do it also if code fails end; This is very usable to assure that resources are freed: MyObject := TMyClass.Create; try x := MyObject.value / 0; // Ooops /0 exception here! finally MyObject.Free; // But the object will be freed. end; > that code. OTTH, if there already is an implementation in a Pascal > dialect (Delphi?), and it's suitable, it would be a good idea to be > compatible to this. So again, could someone make a list of required > features (perhaps with some sample code)? I totally agree. IMO GCC should be compatible with Delphis Object Pascal, since OP is the real standard (1000000+ sold copies of Delphi) and not only a paper-standard. But you guys do it for free, so everything is fine, but Delphi/OP compatiblity would be /great/. If people come to Linux they could easily reuse existing Delphi/OP-code. And yes. Delphi's implementation is /great/ even the new referece counted string types make live much easier. They can save more than > 255, are dynamically allocated and referece-counted. And can for type-conversion easyly typecased with PChar: Procedure MyProc (xxx: PChar); var mystring: String; MyProc (PChar(MyString)); This type of string was introduced with Delphi 2. There are much more things in Delphi/OP which make live easier. The big advantages I see at the moment: - New class model with RTTI, Properties - Exception Handling - AnsiString and WideString (8bit and 16bit-char strings with > 255 chars, String is an AnsiString) - - Interfaces (not really necessary but nice) You asked if there is an description of Delphi/OP. I think there is an helpfile available on www.interprise.com (I'll look if I can find it). But I doubt that it is possible to implement it compatible w/o having a look at Delphi itself. But I hope that I could explain some basic things. And thank you guys for supporting (Object) Pascal. Andreas

2 1