Gpc

gpc@gnu.de

5400 discussions

Re: Objects and GPC
by Peter Gerwinski 04 Apr '97

04 Apr '97

Hi everybody, hi African Chief! It seems that I am no more the only one who uses Objects. :-) According to The African Chief: > Using the latest GPC alpha (9704), I find that I cannot > import objects from a unit. I originally had the source > for TObject (below) in a unit, and used the unit in > this program (test.pas). I had compile errors all > the time. That's strange because when I put TObject below in a separate Unit everything compiles fine. However the resulting code is buggy. :-( I will investigate this. Did you recompile the Unit? The GPI file format changes with every new alpha GPC. > Then, I put the object's source into test.pas > itself, and it compiled. But when I tried to create > a descendant object (NewObj), as seen in the > source below, again, I had compile errors - > complaining about the "initializer element" for > some of the methods not being "constant". I see. You have detected a bug ... even two bugs. Thanks for reporting them! > Can anyone tell why this source does not compile, > even with the -borland-pascal flag? The `--borland-pascal' switch has no effect on this. You do not need to enable Objects, but vice versa, if you specify one of `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', or `--ucsd-pascal', you *disable* OOP. 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Small success!
by The African Chief 04 Apr '97

04 Apr '97

Ahem ... I have now discovered the reason why I could not import my object from a unit (there was no .o file!). Using "--automake" ensures that the .o file is created, and the object imports okay. However, the problem still exists with creating a descendant object. I can now (magically) create one (if the parent object is in a unit), however, if I try to create a new constructor, any call (inside the new constructor) to the ancestor constructor (e.g.., "Inherited Init") causes a GPF ! The parent object is now in a unit, but the descendant object is in the main program. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GPC for HP3000
by Achim Kalwa 04 Apr '97

04 Apr '97

Hello out there! I'm looking for GPC ported to HP3000 systems (PA-RISC cpu). At the office, i have access to two HP3000 machines, but no developer tools. As I'm pascal programmer, i would like to have a compiler on that machine(s). But prior to buying the HP pascal compiler, it would be nice to see if my ideas would work and to get a feeling for the performance. Did someone the port successfully and has a binary "distribution"? Or are there other "free" Pascal compilers fpr HP3000? Thanks in advance Achim achim.kalwa(a)do.netsurf.de

2 1

Objects and GPC
by The African Chief 04 Apr '97

04 Apr '97

Hiya! Using the latest GPC alpha (9704), I find that I cannot import objects from a unit. I originally had the source for TObject (below) in a unit, and used the unit in this program (test.pas). I had compile errors all the time. Then, I put the object's source into test.pas itself, and it compiled. But when I tried to create a descendant object (NewObj), as seen in the source below, again, I had compile errors - complaining about the "initializer element" for some of the methods not being "constant". Can anyone tell why this source does not compile, even with the -borland-pascal flag? It compiles and runs okay with BP7 and BPW. Thanks! { ---- cut -----} Program Test; {$define debug} Type pObject = ^TObject; ChildPtr = pObject; TObject = Object Parent : pObject; Child : ChildPtr; Name : String[255]; Handle : integer; { BP } Constructor Init; Destructor Done;virtual; { Delphi } Procedure Free;virtual; {calls Destroy} Destructor Destroy;virtual; Constructor Create (aOwner : pObject); End; { TObject } Constructor TObject.Init; Begin Parent := Nil; End; { TObject.Init } {////////////} Constructor TObject.Create; Begin Parent := aOwner; End; { TObject.Create } {////////////} Destructor TObject.Done; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Done } {////////////} Destructor TObject.Destroy; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Destroy } {////////////} Procedure TObject.Free; Begin {$ifdef debug}Writeln ('Free!');{$endif debug} Dispose (pObject (@Self), Destroy); End; { TObject.Free } {////////////} Type PNewObj = ^NewObj; NewObj = Object (TObject) Constructor Create (aOwner:PObject); End; { NewObj } Constructor NewObj.Create; Begin Inherited Create (aOwner); Name := 'Object Number 2 is a Child!'; Handle := -40; End; { NewObj.Create } { Program() } Var ThisObj : TObject; Begin Writeln ('Hello World!'); ThisObj.Init; With ThisObj do begin Handle := -1; Name := 'Object Number 1'; Child := New (PNewObj, Create (@ThisObj) ); Writeln ('My handle = ', Handle); Writeln ('My name = ', Name); Writeln ('Child handle = ', Child^.Handle); Writeln ('Child name = ', Child^.Name); Writeln ('Child PARENT handle = ', Child^.Parent^.Handle); Child^.Free; Done; end; { With Ob^ } Writeln ('Hello World Number 2 !!'); End { Program() }. { --- end cut ---} Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Two bugs
by Stephen Lindholm 04 Apr '97

04 Apr '97

These two should not compile, and indeed, do not compile under other compilers. program temp; var a = 1 .. 2; type b: a; begin if 1 then b := 0; end. 1 is not a boolean, yet it is accepted as boolean. b is initialized to an out-of-bounds value.

1 0

Standard Compatibility (was: New Alpha)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Phil Nelson: > According to myself (Peter Gerwinski): > > (*** Does anybody know how UCSD behaves here? I don't want to dig > > out my old Apple //e in order to check this. ***) > Yes, it clips strings and it has a 10 for the default field size. Meanwhile I digged out my UCSD Pascal *documentation*, and it says that UCSD Pascal has a default width of 1, but it clips strings. I did not verify this on the Apple //e, but if the default width would have been something different from 1, I would remember it now. > Borland is the only Pascal compiler that I have used or heard of that does > not clip strings and uses 1 as the default field size. Does someone > know of another one (besides gpc)? Yes, almost every Pascal compiler I know for the PC. I checked it for FPK Pascal and Virtual Pascal: Both have a default width of 1 and don't clip strings. I cannot check it now, but I am sure that Speed Pascal, MS Quick Pascal, and TMT Pascal behave in the same way. Anyway, we should count programmers and source lines, not compilers. AFAIK Borland Pascal has more users than all other existing Pascal compilers together. This does, of course, not mean that Borland's way is the best one, but it means that we must not ignore Borland Pascal. > >The above does not clarify how GPC's default behaviour should be. > It should be ISO Pascal with the de-facto-standard field widths. Why? > >IMHO Borland's method is more logical than what most Standard Pascal > >compilers do. > It may be more logical, but we didn't design the language. We *are* designing a language. I already wrote some weeks ago: It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself. [...] The current design of GPC is to integrate the good features from the many existing Pascal standards, and you can restrict GPC to these standards using compiler switches: --standard-pascal-level-0 Should work --standard-pascal Do conformant arrays work now? --extended-pascal Not yet fully implemented --object-pascal Just started --ucsd-pascal Almost complete --borland-pascal Almost complete --delphi Just started --pascal-sc Just started The default should be the most powerful easy-to-use and easy-to-understand compiler which can be constructed out of these standards plus GNU extensions. This is in the spirit of GCC; `info gcc invoking "warning options"' says: We recommend [...] that users take advantage of the extensions of GNU C and disregard the limitations of other compilers. Aside from certain supercomputers and obsolete small machines, there is less and less reason ever to use any other C compiler other than for bootstrapping GNU CC. If it is possible to have something better (in this case: more logical) than most Standard Pascal compilers, this better solution should be the default, and there must be a compiler switch to emulate those other compilers. And, anyway, we are talking about a default width of 1, not about string clipping, so this would not even violate the ISO Standard. > [...] > I can not live with either being the standard behavior. If you do make > Borland behavior standard, at least make it a configure option to not > make Borland behavior standard so I don't have to maintain local changes > to gpc to get what I really want. Similarly, if you choose to make > Standard Pascal the default behavior, have a configure option to choose > Borland for those who want it. Better yet, make gpc change depending > on whether it is run as gpc (Standard Pascal) or bpc (Borland Pascal). I never intended to make GPC's standard behaviour to emulate Borland Pascal, but I also don't intend to restrict GPC by default to the ISO Standard. GPC shall be something superior to both Borland Pascal and ISO Pascal. It is a very good idea to make GPC's behaviour depending on the name it is invoked with. What about the following: pc ISO 7185 Standard Pascal compiler epc ISO 10206 Extended Pascal compiler bpc Borland Pascal compatible compiler ... (other de-jure or de-facto standards) gpc Integrate all good features (not the misfeatures) of these standards in one compiler. People who need compatibility to other ISO Extended Pascal compilers will invoke GPC as `epc' and will not notice any Borlandish behaviour. (If they do, the may report it as a bug.) Vice versa, those who want a "32-bit Borland Pascal" will call GPC as `bpc'. Those who call GPC as `gpc' will profit from both (and more) dialects. One typical example is to allow components of structured variables as `for' loop control variables (according to Borland). This is a harmless extension to the ISO Standard - nobody will use this unintentionally -, so `gpc' will accept it. (`epc' will not.) Now we can combine this with Extended Pascal's set member iteration (to be implemented soon): for i [ k ] in [ 2, 3, 5, 7, 11 ] do ... I intend, for example, to combine Extended Pascal's schema types with Borland Pascal's object types. > > * When an Integer value is being output with a field width of zero, > > output is suppressed. Is this ISO Standard (doesn't seem so), > > or a bug? > > This is not conforming and needs to be changed. It should be the same as 1. Okay, I will be happy to change this. > > * When a Real value is being output with a too narrow field width, > > other compilers bother to make the output as short as possible. > > Should GPC do the same? > > It should follow 6.9.3.4.1 (ISO 7185) [...] Okay, I'll take care of that. (Although I wouldn't mind if somebody else would hack the runtime library for such things, so I can face schema types instead ...) > > [blank in front of Reals] > > Yes, they are following the standard. I have no problem with the switch > as long as it is not standardly on. Okay. It will be "off" by default. > Is it possible we should ask Juki what the standard behavior should be? > Borland vs Standard? Since Juki is on this list, he should read all this. Hey, Juki, what's your point of view? 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Standard Compatibility [was: Re: New Alpha]
by Kevin A. Foss 04 Apr '97

04 Apr '97

On Thu, 03 Apr 1997 18:52:18 +0200, Sven Engelhardt wrote: >gpc really shall default to borland/turbo-pascal behaviour. You could >implement reading ~/.gpcrc to change that. (For ease this could be done >with a shell script) The cause ain't 'standard' performance, as >thousands >of dos-pascal-programs will be ported to linux. I have to admit I'm in favor of defaulting to ISO standard behavior, but that is just my personal preference. I'm mainly concerned with the last comment... is it true that 'thousands of dos-pascal-programs' will be ported to linux'? I don't see a majority of the DOS-based TP programs being all that useful, or all that many TP programmers perceiving a need to port their software to gpc. Granted there was a lot of good software written with TP and which should be ported, but I think your numbers are over stated. The comment also begs the question. is gpc's role to provide a facility for porting 10 year old DOS programs or for the creation of new programs? I would think primarily the latter and that decisions on gpc's defaults should serve that end. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

[sad@utkux.utcc.utk.edu: Re: Standard Compatibility [was: Re: New Alpha]]
by Phil Nelson 03 Apr '97

03 Apr '97

From: sad(a)utkux.utcc.utk.edu Subject: Re: Standard Compatibility [was: Re: New Alpha] To: phil(a)cs.wwu.edu (Phil Nelson) Date: Thu, 3 Apr 1997 13:51:03 -0500 (EST) In-Reply-To: <199704031835.KAA01150(a)fawn.cs.wwu.edu> from "Phil Nelson" at Apr 3, 97 10:35:05 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > It should not be arbitrary! It should be large enough so MAXINT will > have at least one blank in the field. So in this case, gpc should have > the numbers depend on the MACHINE data type. Choose something like > the number of digits in MAXINT + 1 to be the default integer field size. Agreed, this is nice for number crunching (much like Fortran handles generic write(6,*)) and hence I'd prefer it to default to that. It is not so nice when you want to do fancy stringish output stuff, so I'd think there should be an option (compiler or even better, runtime) to switch to left justified output where so desired. Cheers. Stefan ======================================================================== Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad(a)utk.edu ========================================================================

1 0

Re: New Alpha
by Peter Gerwinski 03 Apr '97

03 Apr '97

According to Frank Heckenbach answering to a mail by Phil Nelson: > Ok, then, if I got this right, you have to do > write(num_var:1) and write(string_var) > for output without spaces, whereas > write(num_var) and write(string_var:1) > both don't work this way. > > This seems a bit inconsistent and confusing to me. To me, too. That's why I prefer Borland's way to default to a width of 0 (or 1 in the above example) if nothing was specified (which does not contradict the standard, BTW), and to treat string values just like all the other ones, i.e. without clipping. > I see that your programs rely on this way, but my programs rely on BP's > way, and I don't think there's anything worse with BP's way than the > standard's way. So, obviously, gpc needs to support both ways. So it's okay that "gpc --borland-pascal" does switch off string clipping, while "gpc --standard-pascal" or "gpc --extended-pascal" turns it on. There must also be a pair of separate switches, e.g. "--clip-strings" and "--no-clip-strings", to make this decision independent of the selected Pascal dialect. (*** Does anybody know how UCSD behaves here? I don't want to dig out my old Apple //e in order to check this. ***) Now what about default field widths? The ISO Standard allows this to be implementation-dependent. If we just take Borland's method it still complies to the standard, so there is no a-priori reason to make this change at all. However it seems to be a de-facto-standard that ISO Pascal compilers have default field widths that are wide enough to ensure that numeric values are always output with leading spaces. Thus `--standard-pascal' and `--extended-pascal' should imply such wide field widths. Of course there must be a separate switch for them, for example "gpc --field-widths=12,24,6" (for Integer, Real, Boolean values). The above does not clarify how GPC's default behaviour should be. IMHO Borland's method is more logical than what most Standard Pascal compilers do. However the only true contradiction between Borland and ISO in this context is string clipping which only occurs in very rare cases (at least in my programs). Thus I could live with string clipping being "on" by default. Concerning field widths, it does not contradict ISO Standard to follow Borland, so we should do that. (Remember that `--borland-pascal' turns string clipping off and that `--standard-pascal' makes GPC behave like other Standard Pascal compilers.) BTW, there are some other strange things in GPC's interpretation of field widths: * When an Integer value is being output with a field width of zero, output is suppressed. Is this ISO Standard (doesn't seem so), or a bug? * When a Real value is being output with a too narrow field width, other compilers bother to make the output as short as possible. Should GPC do the same? * All Pascal compilers I have access to have the "feature" that it is impossible to output a positive Real value without at least one leading blank. This is annoying in some situations, so what about an additional switch, e.g. `--no-real-blank', to disable it optionally? (Better suggestions for the names of all compiler switches are welcome!) That's it for the moment. Sqr ( BTW ), this switcherism makes it more and more necessary to let GPC read in a configuration file, or to use `make' to keep all these switches in a Makefile, or to use RHIDE which provides a menu for them. 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Command-line options and CFG file (was: New Alpha)
by The African Chief 03 Apr '97

03 Apr '97

On Wed, 2 Apr 1997 20:11:12 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> [...] In case you haven't done this, can you >> introduce a .CFG file (like with Borland) where one can >> put all the command line switches that they want to use? > >I have an old version of GCC for some special hardware here (without >source #@*!) which accepts a `@filename' option pointing to a file with >additional options. We could, for example, do the same and make > > gpc @gpc.cfg > >read a file `gpc.cfg' in the current directory. Yes, that would be nice. But why not just let it look for a 'gpc.cfg' file automatically? It could then take whatever it finds there as command line parameters (in addition to any other ones passed at the command line itself). There could also be provision for making comments in the .cfg file). I apprecite that looking for, and reading a .cfg file automatically may be strange to those not coming from a BP or DOS background, so I don't think that this is a wish that requires too nuch attention. >> You can make many sample .CFG files >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people >> can then rename to GPC.CFG or whatever. > >In principle this is not necessary: By default, GPC understands all of >these dialects (as far as implemented) and you can specify one (or more) >of `--standard-pascal', `--extended-pascal', `--borland-pascal' to >restrict GPC's language to the specified dialects. Ok. BTW: having just downloaded and installed GPC 2.0 and some of the DJGPP stuff referred to in the docs, I still can't get anything to compile. The place where I am stuck now when I try to compile is this message: "C:\DJGPP\BIN/ld.exe: cannot open linker script file djgpp.lnk: No such file or directory (ENOENT)" A search through my disk shows that no file with the .lnk extension exists. Any clues? This is not in the FAQ! Thanks. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

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