Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

GNU Pascal beta version gpc-970624
by Peter Gerwinski 05 Jul '97

05 Jul '97

Hello everybody! Here again is a new version of GNU Pascal: gpc-970624. Since we are aiming gpc-2.1 now, this is considered a *beta* version. :-) GPC integrated into GCC ======================= We succeeded to integrate the GPC source tree into that of GCC. Now GPC is compiled and installed just like other GNU compilers. Advantages of this distribution to the users of GPC are: * Easier configuration: GPC is configured automatically when you configure GCC. To build it, simply type "make LANGUAGES=pascal" in the GCC directory. No more VPATH problems with some (read: Solaris) versions of `make'. * Building GCC, G++, ObjC, GPC and G77 (GNU Fortran) from a single source tree is now possible. Benefits for GPC developers: * Easier adaption to different GCC versions. * Better functional separation of GPC sources from the GNU back-end (code shared with GCC) and the GPC specific code. * A first step of further integration of GPC into the main GCC distribution? Other changes since gpc-970510 ============================== General news: * The version number is now again produced manually, so it does reflect the date of release, not of compilation. * The GCC_MINOR version number now yields the expected result of `7'. Bug fixes: * Concatenation of more than two String constants now results in a constant again, as it should be. * Chars passed to formal String parameters work now. * The warning "return type of `main' is not `int'" which occured with Pentium optimization is gone. * Enumerated types now can be exported by Units or Modules and are type-checked more strictly. * Pointers to single-character identifiers like `^A' now work as type specifications in variable declarations. (They no more crash with `^A' character constants.) * GPC no more crashes on errorneous constant definitions. * GPC no more crashes on errorneous initializers of structured variables. * AutoMake with (*$L foo.c *) sometimes appeared to chose the compiler to run at random, and it threw the dice to decide whether to recompile the file or not. This feature is replaced now by a more traditional method: (i) Derive the compiler to run from the extension of the file, and (ii) decide whether to recompile or not from the date of the last change. * Fixed some obvious bugs in the lexical analyzer which never showed up. (The situation was too exotic to appear in praxis.) * Extended Pascal's `ReadStr' (for BP users: this is EP's equivalent to `Val') now accepts numeric values in non-zero-terminated strings. (GPC's strings are not zero-terminated.) * Initialized strings no longer get a trailing `chr ( 0 )'. (Initialized `CString's (aka `pChar's) do; see below.) * Initialization of structured variables containing other structured variables works now. * OOP: Nested subfunctions of methods work now. * Pointer arithmetics now also works on the DEC Alpha, where `SizeOf ( Pointer)' is different from `SizeOf ( Integer )'. * Objects now also work on the DEC Alpha, where the type for sizes of objects is not `Integer' (32 bits) but `LongInt' (64 bits). * Packed arrays now also work on the DEC Alpha which does not like to access misaligned 64-bit words. * Schemata now also work on the DEC Alpha. * Functions returning `Char' values now also work on the DEC Alpha. * Module (Unit) constructors and destructors now also work on the DEC Alpha. (You see: The DEC Alpha is a good platform to test GPC!) UCSD (and Borland) Pascal: * `Exit' handles function return values correctly now. * Functions returning `String' now default to return `String ( 255 )'. Without the `--borland-pascal' switch, a warning is given. (According to EP, `String' is a Schema type in GPC and not limited to 255 characters.) Borland Pascal: * Control character constants like `^A' are now restricted to `^A..^Z' because `^^' happened to crash with double pointer dereferences, etc. (BP has a bug here and does even accept `^;' and `^ ' (with a blank). They might consider it a feature ...) * `Abstract' can be redeclared now. (BP has no built-in `Abstract', but Turbo Vision defines one.) * Assigning contant values to `pChar' (aka `CString') variables works now. * The `write' and `writeln' procedures now work for `pChar's, too. * Calls to procedural parameters now work in expressions, too. * Type casts now work like in BP, no more like in C. Delphi: * GPC now implements the function return `Result' variable. (According to EP it was always possible to implement it manually by declaring "Function foo ( bar: Integer ) = Result: Integer". (And it still is.:)) Extended Pascal: * Subarray access `a [ i..j ]' for non-Strings is now warned about in `--extended-pascal' mode. * Pointers to pointers to undiscriminated Schemata (e.g. Strings without specified length) work now. * Schemata are (read: should be;) initialized properly now in all situations. GNU extensions: * A new option `--executable-file-name' or (*$executable-file-name="foo"*) now provides an alternative mechanism (apart from `-o foo') to specify the executable output file. While `-o' can only be specified at the command line, this switch can be written in the source as a compiler directive. If the name is not explicitly given, it is derived from the source file name which contains the `Program' declaration. * A new option `--ignore-function-results' or (*$ignore-function-results *) now allows to ignore values returned by functions without (*$X+*). Since this is not as dangerous as, say, pointer arithmetics, it has got a separate switch. It has a counterpart `--no-ignore-function-results'. * `--extended-syntax' now has a counterpart `--no-extended-syntax'. * `TypeOf ( MyObj )' is not accepted as an lvalue any more; instead, you can use `AssignType ( MyObj, MyVmtLink )'. * Assignment of the return value of a function through `asm' statements is now recognized, so you won't get a superfluous "warning: return value not assigned" any more. * Pointer arithmetics: `inc ( p, n )' now increases the address pointed to by `n * SizeOf ( p^ )' rather than just `n'. * GPC has new integer types now. Below is a table with their sizes in bits and their equivalents in (GNU) C. The size is the same for all platforms I have access to, but I am not sure whether this will always and everywhere be the case. However, compatibility to GNU C is guaranteed to work to the extend of the GNU GPL. ;-) The `*Int' types are signed (integer), the `*Card' types unsigned (cardinal numbers). The `*Word' types are unsigned, too, but should be thought of having undefined sign; they are intended to be used where signedness does not matter. Bits Signed Unsigned undefined (GNU) C equivalent 8 ByteInt ByteCard Byte [signed|unsigned] char 16 ShortInt ShortCard ShortWord short [unsigned] int 32 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord long [unsigned] int 64 LongInt LongCard LongWord long long [unsigned] int 64 LongestInt LongestCard LongestWord long long [unsigned] int In addition, you can define the number of bits for `Integer', `Cardinal', and `Word' types by putting it in parentheses, Type Int16 = Integer ( 16 ); (* 16 bits *) Unsigned17 = Cardinal ( 17 ); (* 17 bits; stored in 32 bits *) (* except when in packed arrays *) (* and records (or on machines *) (* with 17-bit registers:-). *) Answer = Word ( 42 ); (* Stored in 64 bits *) The size is rounded up to the next unit the machine can access, usually a power of 2 with 8 bits being the smallest possible size. * Subrange types can be packed now: Type Foo: -12..127; (* Takes 4 bytes (fast access) *) Bar: packed -12..127; (* Takes 1 byte (saves memory) *) Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Acknowledgement =============== We thank everybody who took part in the discussion about integer types and other extensions for good ideas. We thank Larry Carter, Frank Heckenbach, Abimbola A. Olowofoyeku, Markus Gerwinski, Berend de Schouwer, Maurice Lombardi, Phil Robertson, Bernhard Tschirren, and Dario Anzani for finding the bugs. We thank the IFF (Institut fuer Festkoerperforschung) of the FZ Juelich, Germany, for the opportunity to test this new version of GPC on a DEC Alpha computer. Greetings, Peter Gerwinski Jan-Jaap van der Heijden <peter.gerwinski(a)uni-essen.de> <j.j.vanderheijden(a)student.utwente.nl>

2 1

Re: Delphi classes
by Ken Linder 04 Jul '97

04 Jul '97

At 04:27 PM 7/4/97 +0200, Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: >> Right, only published propertied show up in the object inspector. I >> think for now, in GPC anyway, allow 'published' and treat it as a 'public'. >> When GPC moves to X-windows or gains a visual/graphical development tool, we >> should be able to utilize it better. > >Good idea. However, what is this object inspector, anyway? To me, it sounded >like a development tool, but now it seems like it's something used at >runtime, right? What do programs do with it? >-- >Frank Heckenbach, Erlangen, Germany >heckenb(a)mi.uni-erlangen.de >http://www.mi.uni-erlangen.de/~heckenb/links.htm > The Object Inspector is a development tool that allows the developer to 'non-programaticaly' set the properties of an object before instantiation. Here is a quick example: ... published Caption : string; Status : (Maximized, Minimized, DontKnow); SomeNum : integer; ... Lets say the above is part of an object that can be 'dragged' onto the desired window. (Yes, I know I am talking Windows here) Selecting the object after it is dragged onto the window will make the 'object inspector' display all 'published' properties of that object. The object inspector will allow the programmer to enter some string for Caption, select one of the enumerated values for Status, and an integer for SomeNum. At run-time the object inspector don't exist. It is strictly part of the Delphi (and C++ builder) development tool. You can also attach specialized editors for complex properties. The inspector also allows the programmer to attach functions and procedures to events but that is VERY windows based due to the message passing nature of the Windows OS. Later... Ken L kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Re: Delphi classes
by Frank Heckenbach 04 Jul '97

04 Jul '97

Marius Gedminas wrote: > In Delphi you can declare a method 'virtual' or 'dynamic' and when you want to > override it in an descendant class, you must do it with 'override' directive. And what happens if you don't use "override"? Does it overload the methods then? (Does it have overloading at all?) > I think it's only needed for Delphi compatibility, where TObject is the > ultimate ancestor of all objects. Perhaps another compiler switch (for > Delphi compatibility)? I agree (see below). Peter Gerwinski wrote: > It's "class" = "reference to object". Fortunately, the GCC front-end > is able to deal with such things, Fine! :-) (Front-end? Or back-end?) > so we "only" have to implement the > syntax into GPC - and take care that it doesn't break other applications > of reference types such as `Var' parameters and procedural variables. Yes. Are value and reference parameters of class type the same, then (in Delphi)? Or do reference parameters pass a pointer/reference to the reference, i.e. do they allow destroying and recreating the object? Are pointers to classes allowed in Delphi, and what do they mean? > We should try to be compatible to Delphi and the ANSI Object Pascal draft. Yes. And it would be even better if there was any documentation about them available... ;-) For Delphi, I don't have much hope since it's non-free, but Object Pascal? (Should I do another Yahoo search...? ;-) Larry Carter wrote: > > > > 6. All classes to have the same ultimate ancestor object. > > When I actually started to think about this, I realized how this could be > a problem. In Delphi, this commmon object works great becuase it provides > all the basic machinery neccessary for all objects, however, this is > machinery that is specific to the Intel running Windows environment, the > memory model etc. An object of this type in GPC would probably be very > bloated, making all its decedants bloated, becuase of all the different > environments it would have to handle. Perhaps a library of foundation > objects for each OS?? Especially since this really has little to do with > the compiler itself anyway! :) I think the problem we're facing is that Delphi is not really a "standalone" language, but partly tied to one special environment. Since for gpc, portability is a more important goal than conformance to other (non-standard) compilers, I agree that such things do belong into libraries. AFAICG, objects in Delphi are typically things like windows, editors, dialogs and such "big things". Other use of OOP is for "small things" like vectors or certain data types with their operations which are completely independent of OS's and such. The African Chief wrote: > >Saves declaring those "PFoo" types, OTOH makes it impossible to declare > >global or local objects variables (without the overhead of allocating > >memory). If we have objects and classes, the programmer can choose what > >(s)he prefers. > > Delphi also supports both Objects and Classes - With the differences like I described them? > so it would be nice if we could as well. gpc will certainly not remove objects when classes are implemented. :-) > >> [b] the constructor does the heap allocation stuff, > >> e.g., "Foo := MyFoo.Create" > >> *allocates memory for Foo "(New, Foo)" > >> *calls Foo^.Create (constructor) > > > >So it's the same as "Foo := New(MyFoo, Create)" in BP? > > More or less. I'd like to know it exactly. Is there any difference (besides the different syntax, of course)? > Delphi destroys all objects that it creates itself. However, > if you manually create an object by calling its constructor, > you have to destroy it yourself with a call to "Free". Sounds logical. But when does Delphi create objects by itself? AFAIK, gpc doesn't do this yet, so we'd have to adopt this as well!? > I suspect that Delphi sets them to Nil as well, both before > construction and after destruction - otherwise the checks for > "Nil" made by TObject.Free would not make any sense, since > there is nowhere in the source code where these things are > manually set to Nil. So I think gpc should do this as well, at least for references (to classes). > Probably so. However, Classes are different from "mere" objects, > and I suspect that with Delphi, (assuming that Foo is an instance > of a Class, and not of a mere object) if you do; > > New(Foo); > Foo.Create; > > What "Foo" is pointing to may actually be undefined - and you will > certainly get an exception when you try to do anything with "Foo". If it's undefined in Delphi, it wouldn't hurt if there is a defined behaviour in gpc. :-) > In this case, it *is* necessary for Delphi compatibility. In Delphi > all classes are descendants of TObject. Doing this in Delphi; > > [...] > > The VCL depends on this being so, and we should also > support it (not least because Delphi programmers expect > this to be so). This means of course that TObject then has > to become part of the GPC RTS. For present purposes, it > only needs to be something like this; Sorry, but it probably can't be in the RTS, I think, because non-Delphi programs use the same RTS, and should not have this type. My suggestion: implement a compiler switch like '--base-class="TObject"' so that gpc will use this class by default as a parent class if no parent is declared (and, of course, if the current class is not "TObject" itself ;-). With "--delphi", this switch could be set automatically. Then, TObject could be declared in some unit (like System for Delphi). (For "completeness", we could also have '--base-object' or so...) BTW: This is similar to the '--uses="system"' I suggested -- things that are not really the job of the compiler, but needed for compatibility. Such switches seem to make the difference to the compiler as small as possible. For BP/Delphi programs that are just recompiled with gpc, these switches can be used. When the programs are really ported to gpc, these things would probably put into them programs themselves, and the switches would not be used anymore (neither for native gpc programs), I guess. > Type TObject = Class > Constructor Create; virtual; > Destructor Destroy; virtual; > Procedure Free; virtual; > end; {I am not sure about the "virtual" bit} > > {and any other (private) stuff needed for any compiler > magic that we need to do; The only magic field in gpc would be the "VMT" link. > Like I said, "Create" and "Destroy" are empty in TObject > (i.e., they contain just an empty "begin end;" block). > "Free" checks whether the pointer is Nil, and if it is not, > it calls Destroy. Nice little "trick", but not very systematic. "Free" is a method of an object, and this object can be "nil^"!? Technically, it works, but "Free" must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd prefer a procedure... (Or should we regard it as defined behaviour to call a static method of a non-existing object if the method doesn't access any fields of the object?) Larry Carter wrote: > > Saves declaring those "PFoo" types, OTOH makes it impossible to declare > > global or local objects variables (without the overhead of allocating > > memory). If we have objects and classes, the programmer can choose what > > (s)he prefers. > > Delphi does not allocate memory for object variables untill the object is > actually created with its create method. Yes, I understood this. What I meant is, you can declare BP (and gpc) objects globally or locally (if you know the exact type at compile time), so they will be located in the data segment or on the stack, and no memory has to be allocated at all. (Just a minor optimization for most cases, but e.g. for small local objects in a frequently called procedure it could make a real difference.) > In Delphi, the common object ancestor (TObject) provides the most basic > methods and properties that ALL objects need (creation, destruction, > etc.). These are the methods/properties that are unlikely to be > overridden (its rare that you would need a different destructor for > example) Sorry? I use different destructors all the time! E.g., if the object "possesses" other objects, it has to destroy them in its destructor. Or did you mean another destructor of another name (but that's not overriding)? > and having a common ancestor provides the programmer with a ready > to go foundation for his/her objects. I think a common ancestor is the > right way to go. Yes, for a library. Ken <kc7rad(a)vegasnet.net> wrote: > Having the 'private' declarations visible anywhere within the unit in > which it was defined is sort of a compatability thing with C++ 'friends'. I had this suspicion, too. So I think, with "--borland-pascal", we should define the visibility like in BP. For the standard gpc mode, however, we should limit it to the class itself, and instead introduce friends like in C++ (one of the useful features of that language, IMHO). > Correct me if I am wrong, but a C++ class can be defined as being 'friends' > with another class. Since they are 'friends', they can share certain > properties. I personaly don't care for this. There are better ways of > access properties in other classes! Plus this breaks the idea of 'object > oriented' programming and provides a way around the OO paradigm. Well, I haven't had a need for them in my BP programs (and haven't made use of the extended visibility in BP), but from some exercises I did in a C++ course, ISTR that they can be useful sometimes... > Right, only published propertied show up in the object inspector. I > think for now, in GPC anyway, allow 'published' and treat it as a 'public'. > When GPC moves to X-windows or gains a visual/graphical development tool, we > should be able to utilize it better. Good idea. However, what is this object inspector, anyway? To me, it sounded like a development tool, but now it seems like it's something used at runtime, right? What do programs do with it? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Delphi classes (Was: bugs, incompatibity, function attributes)
by Ken 03 Jul '97

03 Jul '97

>>Is this the same as "public" in C++ (= visible to everyone)? I, personally, >>would prefer "public", "protected" (=visible only to descendants) and >>"private" (=visible only to the type/class itself -- BTW, BP does it a bit >>differently, and extend the visibility of private methods to the whole unit >>it's declared in. I don't see any reason or advantage of this). So, perhaps >>we could allow all those keywords, including "published", in any order, also >>possibly repeated (unlike BP). > >In Delphi there are four such directives: > > public - like in BP - visible for everyone > private - like in BP - visible only for this unit (I don't see any > advantages too) Having the 'private' declarations visible anywhere within the unit in which it was defined is sort of a compatability thing with C++ 'friends'. Correct me if I am wrong, but a C++ class can be defined as being 'friends' with another class. Since they are 'friends', they can share certain properties. I personaly don't care for this. There are better ways of access properties in other classes! Plus this breaks the idea of 'object oriented' programming and provides a way around the OO paradigm. > protected - visible for this class and its descendants > published - same as public, but also accessible at the design time > (in Object Inspector) - I don't program Delphi, but as I > remember only properties were placed here. Right, only published propertied show up in the object inspector. I think for now, in GPC anyway, allow 'published' and treat it as a 'public'. When GPC moves to X-windows or gains a visual/graphical development tool, we should be able to utilize it better. Just my thoughts... Ken L kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Delphi classes (Was: bugs, incompatibity, function attributes)
by Peter Gerwinski 03 Jul '97

03 Jul '97

According to Frank Heckenbach: > > Besides, removing "asmname" would break some existing programs (including > a published one of mine)... Okay, I will let it in. > So "class" = "pointer to object", approximately... It's "class" = "reference to object". Fortunately, the GCC front-end is able to deal with such things, so we "only" have to implement the syntax into GPC - and take care that it doesn't break other applications of reference types such as `Var' parameters and procedural variables. > [Constructors and destructors ...] We should try to be compatible to Delphi and the ANSI Object Pascal draft. > This reminds me of C++'s "reference types" (not only for objects, but for > any types). I.e., a pointer internally, but dereferenced automatically when > necessary. I think they could be quite useful sometimes, anyway, and if > they'll be implemented (syntax?), we'd have "class" = "reference to > object"... General-purpose reference types? :-/ That's C++'s workaround for the missing `Var' parameters. I think this would cause more confusion than goods. > [public, published, private, protected, ...] So, perhaps > we could allow all those keywords, including "published", in any order, also > possibly repeated (unlike BP). I agree. > > 6. All classes to have the same ultimate ancestor object. > > The same discussion as with objects recently... ;-) > Is this really necessary (if so, for what?), or is it sufficient if all > classes in a given library use the same ancestor by convention? I don't like this at all. This is very useful as a convention when writing a library, but it is not the job of the compiler. Since Delphi seems to do it this way, GPC should behave the same in `--delphi' mode, but not by default. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes (Was: bugs, incompatibity, function attributes)
by The African Chief 03 Jul '97

03 Jul '97

On Thu, 3 Jul 1997 01:13:18 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: [...] >> 2. [a] a Class instance becomes a pointer to the class; >> (or is it that the Class itself is a pointer to an object/class?); > >I think the latter would be a more consistent interpretation (at least for >us, even if Delphi does it otherwise). So "class" = "pointer to object", >approximately... I agree. I think this is how Delphi does it too. "Procedure Foo (Bar: TObject)" in Delphi is the same as "Procedure Foo (Bar: pObject)" in BP. However, Delphi automatically deferences "Bar" every time it is referred to. >> e.g., "Var Foo : MyFoo" >> = "Var Foo : ^MyFoo" in the current OOP model > >Saves declaring those "PFoo" types, OTOH makes it impossible to declare >global or local objects variables (without the overhead of allocating >memory). If we have objects and classes, the programmer can choose what >(s)he prefers. Delphi also supports both Objects and Classes - so it would be nice if we could as well. >> [b] the constructor does the heap allocation stuff, >> e.g., "Foo := MyFoo.Create" >> *allocates memory for Foo "(New, Foo)" >> *calls Foo^.Create (constructor) > >So it's the same as "Foo := New(MyFoo, Create)" in BP? More or less. >What about destructors? Does Delphi still use "Dispose", or has it another >syntax too, or does it dispose of objects automatically. According to the docs, the destructor destroys the object and releases the memory allocated to it. You are advised that you seldom need to call the destructor directly, and that you should call the "Free" procedure instead, to release memory and dispose of the object. It says that "Free" checks to see if the pointer is nil before calling Destroy and is also more efficient in code size. However, when you look at the code for TObject.Destroy, it actually does nothing. Same thing with the constructor (TObject.Create). Thus all the memory allocation and deallocation stuff seems to be done with compiler magic. TObject.Free contains ASM code which tests what is in EAX (I am talking about 32-bit Delphi here), and does some other stuff with EAX and ECX and then does something with the VMT which I assume is a call to the ECX. "Destroy" destructor. Those of you who know Intel asm, will probably understand all this. >(C++, BTW, does the latter. It destroys e.g. local objects at the end of the function >automatically. Delphi destroys all objects that it creates itself. However, if you manually create an object by calling its constructor, you have to destroy it yourself with a call to "Free". >This is possible because in C++ every class has exactly one >destructor. I guess they set the pointer to nil automatically at the >beginning (and set it back to nil if the destructor is called manually), >so they can easily find all local objects that "exist" and destroy them.) I suspect that Delphi sets them to Nil as well, both before construction and after destruction - otherwise the checks for "Nil" made by TObject.Free would not make any sense, since there is nowhere in the source code where these things are manually set to Nil. >> *Foo now points to whatever >> "Foo.Create" - should generate an exception >> because Foo needs to be assigned to the >> constructor > >AFAICS, calling a second constructor does not even have to be forbidden -- >at least in gpc. Constructors can be called like normal methods from an >initialized object, though this is certainly uncommon practice. Probably so. However, Classes are different from "mere" objects, and I suspect that with Delphi, (assuming that Foo is an instance of a Class, and not of a mere object) if you do; New(Foo); Foo.Create; What "Foo" is pointing to may actually be undefined - and you will certainly get an exception when you try to do anything with "Foo". That may be why you need to assign "Foo" to its constructor - viz; Foo := TMyFoo.Create; >> 4. Virtual methods to be overridden must be overriden >> with the "override" directive; the "virtual" directive merely >> creates a new method (or at least, don't reject the >> "override" directive in a "Class" definition) > >Does this mean you have to use "virtual" for *every* method in Delphi, or >what is meant by "create a new method"? Somebody else (Marius Gedminas) has responded to this. >> 5. Allow "Published" methods (or at least, don't reject the >> "published" directive in a "Class" definition). > >Is this the same as "public" in C++ (= visible to everyone)? I, personally, >would prefer "public", "protected" (=visible only to descendants) and >"private" (=visible only to the type/class itself -- BTW, BP does it a bit >differently, and extend the visibility of private methods to the whole unit >it's declared in. I don't see any reason or advantage of this). So, perhaps >we could allow all those keywords, including "published", in any order, also >possibly repeated (unlike BP). And this too. >> 6. All classes to have the same ultimate ancestor object. > >The same discussion as with objects recently... ;-) Yes ;) >Is this really necessary (if so, for what?), or is it sufficient if all >classes in a given library use the same ancestor by convention? In this case, it *is* necessary for Delphi compatibility. In Delphi all classes are descendants of TObject. Doing this in Delphi; Type MyFoo = Class end; is exactly the same as doing this; Type MyFoo = Class(TObject) end; The VCL depends on this being so, and we should also support it (not least because Delphi programmers expect this to be so). This means of course that TObject then has to become part of the GPC RTS. For present purposes, it only needs to be something like this; Type TObject = Class Constructor Create; virtual; Destructor Destroy; virtual; Procedure Free; virtual; end; {I am not sure about the "virtual" bit} {and any other (private) stuff needed for any compiler magic that we need to do; Delphi contains some more stuff in TObject - most of them are all ASM, and I don't have a clue as to what they do }. Like I said, "Create" and "Destroy" are empty in TObject (i.e., they contain just an empty "begin end;" block). "Free" checks whether the pointer is Nil, and if it is not, it calls Destroy. So, TObject itself is easy to implement - but I don't know what compiler magic will need to be done to make sure that everything else works as expected. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Some new features
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > > > What about extending (*$executable-file-name="foo"*) to accept > > > a directory? Or else (*$executable-path-name="/foo"*) and > > > (*$object-path-name="/bar"*)? > > > > I don't agree. The *name* of the executable can be considered part of the > > program. The *path* where it will be stored will be system dependent, so the > > path, IMHO, does not belong into the source, but on the commandline (or into > > a (system or user or project specific) config file, of course). > > A directive (*$Foo="Bar"*) is always equivalent to a command-line > option `--foo="Bar"'. I was just thinking about reasonable names > for these options. Ok, "executable-path-name" and "object-path-name" seem ok to me. I just doubt whether it's wise to allow putting them into the source (doing so would probably lead to "unexpected results" when moving the files to another system). Or are all command line options automatically allowed in the source now? > > > > - Passing the actual size for untyped (resp. void) parameters, so it can > > > > be access with sizeof. > > > > var x:void -> like C > > var/const x -> like BP > > BP does *not* pass the size of untyped parameters to the procedure. Sorry, I meant to say "like BP with extensions"... ;-) > Changing GPC would break compatibility to both C and BP; the latter > being unimportant because nobody will consider it a feature *not* > to have the size of a variable. I wouldn't even say it breaks compatibility. It just adds a feature ("backward compatible"). Programs written for BP cannot fail with gpc because of the additional parameter. > OTOH, many C libraries rely on a > `void*' parameter *not* being followed by a `size' parameter. Ok, then "void" works for these cases (passing an untyped pointer by value works, too). > Instead of changing the meaning of `Var foo', we are IMHO better off > when introducing a *safe* mechanism to pass variables of varying type > (and number). Procedure overloading will be "half the rent". ;-) But what about the other half? Overloading will only handle those cases where only a certain number of types are admitted. Other cases (like BlockRead/ -Write, Move, FillChar, to speak in BP terms) allow any type, so overloading doesn't help there. And since BP compatibilty is not really broken, I'd still vote for this. > > For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). > > gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". > > Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that > > works on both. :-( Since we can't change BP, we should make gpc recognize > > "@ProcVar", perhaps also only in "--borland-pascal". > > Okay; I have put it on my list. > > Plan: Recognize it, but warn. With `--borland-pascal' (same as > (*$borland-pascal*) :-), don't warn. Oh, oh... things seems to be much more difficult than I thought... :-( I saw that there could be problems with function type variables, resulting from the possible confusion between their addresses and the function results -- especially difficult if the function result type is a pointer type. Additionally, there can be manual type casts, and finally there's BP even more strange syntax "@@", meaning the address of the procedure/function type *variable*. So I did some tests, and now I'm completely confused! Since I don't know what the standard requires, I don't even know what are bugs, and what are features... That's why I'm posting the results without any comments. The first program: program x; {$x+} {$f+} {Write a pointer (with BP: only the offset, but this doesn't matter here)} procedure wp(p:pointer); begin writeln(integer(p)) end; {Test function} function y:pointer; begin y:=nil end; type t=function:pointer; var va:integer; v:t absolute va; begin v:=y; {Let v point to y} wp(@va); {Should give the address of the variable v for reference purposes} wp(@y); {Should give the address of the function y for reference purposes} {6 different ways of accessing some addresses...} {$ifndef __GPC__} wp(v); {$endif} wp(@v); {$ifndef __GPC__} wp(@@v); {$endif} wp(pointer(v)); wp(pointer(@v)); {$ifndef __GPC__} wp(pointer(@@v)); {$endif} end. The results with BP are (where "v" means the actual address of v, "y" that of y, and "0" means nil): v,y,0,y,v,0,y,v gpc gives (where "-" means, doesn't compile, and "?" is a seemingly arbitrary value): v,0,-,v,-,?,v,- With the SP syntax "^function:pointer", the "?" becomes 0. With the next program, gpc says "invalid lvalue in address expression" in line 4: program x; var a:procedure; b:integer absolute a; begin end. With this one, it says "void value not ignored as it ought to be" and "initial value is of wrong type" in line 5: program x; procedure y; begin end; var a:procedure value y; begin end. All I can see that the results are "a little bit" different from BP. :-( The last two programs seem to show that gpc tries to "evaluate"(?) a procedure when it shouldn't...!? Since I don't really understand what's going on, I have no ideas how to "fix" it. At least, we have a different syntax in BP and SP, so we could use different semantics if necessary (see above ;-)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: latest wip
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to Bill Currie: > > I grabbed the 2.1 (01?) beta. Is that the correct verstion to work off? Yes. We call it gpc-970624. The next beta release is likely to follow within the next weeks. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to Frank Heckenbach: > > [...] -- or is it an instance of the "cannot write > longint variables" known bug? It is. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: latest wip
by Peter Gerwinski 02 Jul '97

02 Jul '97

Bill Currie wrote: > > Where can I get the latest WIP version? What's that? > Never mind, just found it (DOH! blind as a bat) :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

2025

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 July 1997