Gpc

gpc@gnu.de

5400 discussions

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

10 Jul '97

Pierre Phaneuf wrote: > Frank: you could just do an include file with all the path options, and > you just change this file... That's how I do almost every thing (compiler > options and defines in a separate "config file" which I include > everywhere). Well, I could, but I think that's a bad idea! Things like paths do not belong into the source since they're system dependent. (I know that in C it's common to have to edit some source files or makefiles before compiling, but that's one of the many things I dislike about C.) For compiler options that affect the source (most of them), it's ok for me to put them into the source, but path options I'd like to see in system dependent things like scripts, aliases and/or environment variables... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by A.A. Olowofoyeku 09 Jul '97

09 Jul '97

Pierre Phaneuf wrote: > On Wed, 2 Jul 1997, The African Chief wrote: > > > 6. All classes to have the same ultimate ancestor object. > > This is done manually (by having all your objects inherit from TObject > somewhere). In Delphi, it doesn't need to be done manually. If you write; Type FooObj = Class end; It is *exactly* the same as if you had written; Type FooObj = Class(TObject) end; > Or maybe you mean we could do this: > > var > C: class; I am not sure you can do that, or that you should be able to do it. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12(a)cc.keele.ac.uk) Author of: Chief's Installer Pro v3.60 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/

1 0

Re: Delphi classes
by Frank Heckenbach 09 Jul '97

09 Jul '97

Peter Gerwinski wrote: > Well, `CommandEnabled' is > not a virtual method, and the body of `CommandEnabled' does never refer > to any data fields of the object. (So why it's a method then???) Or rather, why are the relevant variables global (argh!), and not fields of the correct objects? > How did Borland solve this problem in BP7? > > > const > T: PView = nil; > > ... > P^.Disabled := not T^.CommandEnabled(Command); > ... If I were them, I'd have "improved" the compiler to accept "P^.Disabled := not nil^.CommandEnabled(Command);" in order to save the variable... ;-) > It's great, isn't it? Now you see why I do not want to trust Delphi and > VCL and prefer to hack GPC instead ... : Gee, I guess that means Delphi was created by a staff of idiots. : -- : - Steve Teixeira : steixeira(a)corp.borland.com Yesterday in c.l.p.b.! NO JOKE! :-) (Subject: Re: Programming more, sleeping less. How do you stay awake?) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Delphi classes (Was: bugs, incompatibity, function attributes)
by Frank Heckenbach 09 Jul '97

09 Jul '97

The African Chief wrote: > >Sounds reasonable. So should we just change "asmname" to "name"? > >Or keep both? > > I think we should keep both. "Asmname" is intuitive, but > "name" is good for Delphi compatibility. Besides, removing "asmname" would break some existing programs (including a published one of mine)... > 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... > 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. > [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? Why not! Shorter to type, perhaps easier to read (once one gets used to not looking for "New"). What about destructors? Does Delphi still use "Dispose", or has it another syntax too, or does it dispose of objects automatically. (C++, BTW, does the latter. It destroys e.g. local objects at the end of the function automatically. 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.) > *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. > [c] deference it automatically; > e.g., "Foo.Bar := 12" (instead of "Foo^.Bar := 12") 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"... > 3. Allow virtual constructors (or at least, don't reject the > "virtual" directive in a "Class" constructor's definition) AFAIK, this is planned, anyway. > 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"? > 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). > 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? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

4 4

Re: Some new features
by Peter Gerwinski 09 Jul '97

09 Jul '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > 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. > > > - 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. 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. OTOH, many C libraries rely on a `void*' parameter *not* being followed by a `size' parameter. 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". ;-) > 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. 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]

2 1

Re: bugs, incompatibity, function attributes
by The African Chief 09 Jul '97

09 Jul '97

On Wed, 2 Jul 1997 00:56:42 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: [...] >> 3. Delphi's "name" directive; >> This is exactly the same as GPC's "asmname" directive. We can >> implement this simply by also allowing just the use of "name" in any place >> where "asmname" would be allowed (i.e., we can dispense with the "asm" >> part of the "asmname" directive). That way, we get the best of both worlds! > >Sounds reasonable. So should we just change "asmname" to "name"? >Or keep both? I think we should keep both. "Asmname" is intuitive, but "name" is good for Delphi compatibility. / begin off-point On the question of Delphi compatibility, any chance of supporting Delphi's "Class" construct? I know that there are enough differences between "Class" and "Object" to make supporting "Class" a non-trivial exercise, but we could make a start. As a starting point, I suggest this (if it won't be too difficult, and if it won't distract you from other more pressing things); 1. Allow this to compile; Type MyFoo = Class { blah, blah } end; 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?); e.g., "Var Foo : MyFoo" = "Var Foo : ^MyFoo" in the current OOP model [b] the constructor does the heap allocation stuff, e.g., "Foo := MyFoo.Create" *allocates memory for Foo "(New, Foo)" *calls Foo^.Create (constructor) *Foo now points to whatever "Foo.Create" - should generate an exception because Foo needs to be assigned to the constructor [c] deference it automatically; e.g., "Foo.Bar := 12" (instead of "Foo^.Bar := 12") 3. Allow virtual constructors (or at least, don't reject the "virtual" directive in a "Class" constructor's definition) 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) 5. Allow "Published" methods (or at least, don't reject the "published" directive in a "Class" definition). 6. All classes to have the same ultimate ancestor object. Of all these, numbers 1 and 2 are the most pressing (for me at least), and will go a long way to improving GPC's Delphi compatibility. The others are not that urgent and can come much later (perhaps they can be added to the "to do" list). Does this sound like too much of a distraction at present? / end off-point 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

2 1

Re: SH**! (Sorry) - Procedural Types
by Bernhard Tschirren 08 Jul '97

08 Jul '97

> >Okay, I succeeded to reproduce the bug under plain DOS. It does not show up >in an OS/2 DOS box nor in the Linux DOSemu. > >I am after it. Please relax. (-: YAY!! I just realised what is (probably) causing the problem. GPC supports two versions of procedural types - Borland and GPC. Unfortunately, GPC does not know which version it is compiling. For example: Var Proc = ^Procedure; [...Code...] Begin Proc = @SomeProcedure; [...More Code...] Proc^; Sometimes GPC, for some reason, parses this as a BP End; procedural type, so the ^ is not supposed to be there. It would compile OK if the ^ were removed! HOWEVER, the next time GPC might decide to parse it as a GPC version, so the ^ must be present. And that is all that there is to it! Simple! :-) Now, fixing it is a different story... Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

__cstring__ question & comment
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to Ken Linder: > > the compiler will generate code to convert the string schema type to a real > CString with '/0' termination and everything... Am I right or was I seeing > things? (it is rather late here in Las Vegas, NV, USA) BTW, I am using ver > 2.0 GPC on Linux and when I tried it, got an 'incompatible type' error. No > suprise there :^} `CString' handling has been significantly improved since the days of gpc-2.0. Please take part in beta-testing gpc-970624, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/. > Why do we have __cstring__ anyway? It seems as though we could get away > with just declaring a type like: CString = ^Char Unless it does something > else I don't see yet |-) It's needed for compatibility with C, Borland Pascal, and Delphi. (For the latter cases it can also be called `PChar' now.) And, BTW, in gpc-970624 you can drop the underscores. 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

Delphi definitions and such...
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to Ken Linder: > > I just thought we ought to get some definitions out of the way regarding Delphi. > > 1) Delphi > Development tool IDE) and compiler/linker/interactive debugger. > Strictly NOT platform independant. Only implemented OS (if you could call > it that :^) is the group of Windows OSs. (Although I did read that there is > an IBM AS400 version of Delphi (hmmm... interesting!)) Okay with me, but just to keep the confusion up, I must correct you below: > 2) Object Pascal > A superset of Borland Pascal. The language that is compiled by the > Delphi compiler. Through the utilization of the VCL, the Delphi IDE is > partialy built on Delphi. There is yet another Object Pascal which is an extension of ISO-10206 Extended Pascal. When saying "Object Pascal", I usually refer to this one, while I call the other thing "Delphi" - thus contradicting your definition #1. But I could live with speaking about the "Delphi language" here, reserving "Delphi" for the development environment. > This version of pascal is not standard but seems > to be an extension of ISO 7185. No, it does not include ISO-7185. It has some common things with ISO-7185, that's all. OTOH, Borland's versions of Pascal are extensions of UCSD-Pascal (with small exceptions). 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
by The African Chief 08 Jul '97

08 Jul '97

On Mon, 7 Jul 1997 17:55:36 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >This is the point where I must ask: What you mean with "Delphi"? > >So far, I have seen four definitions: > > 1. the language definition, > > 2. the compiler (including compiler switches and such), > > 3. the compiler and the VCL, or > > 4. the compiler, the VCL, and development tools (the IDE plus all > the tools for "visual programming"). > >When speaking about Delphi compatibility for GPC I refer to meaning >#1 above. #1 will suffice for me. >#2 is out of range, but one can work around this by using >(*$ifdef*)s for incompatible compiler switches. (* There is only one >thing in GPC preventing us from really doing so: the missing {$ifopt x+}. >That's still planned. *) Most people who want to have a Delphi-com- >patible system mean #4, but could live with #3, too. What I personally >aim is #1, but I am almost sure that once we have #1, somebody else >will create #3, and perhaps even #4. :-) I don't think #3 is of any use without #4 (i.e., why have the VCL without the IDE, the object inspector, and the object repository?). Realistically, if we can achieve #1 (i.e., support Delphi's "Object Pascal" language) then I think the rest will happen as people write their own classes, and maybe even a class library based on Object Pascal. 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

Jump to page:

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