Gpc

gpc@gnu.de

5400 discussions

Re: Separate Compilation
by Peter Gerwinski 07 Nov '97

07 Nov '97

According to richard.kerry(a)quantel.com: > > Hello, > Could somebody please either : > 1. Direct me to - info -f gpc -n "Source structures" at least explains how to use Units, and in info -f gpc -n "Extensions" you can read about Modules. This second documentation is somehow outdated; many things which are mentioned as missing features are implemented meanwhile. > or : > 2. Send me - > a comprehensive explanation of separate compilation using gpc, including > examples that clearly show which bits are in different files and how the > other bits pick up their definitions. And also including any > alternate/non-standard/old-fashioned techniques that are still usable. Coming below. > I am working on a very large project, developed using Oregon Pascal. The > separate compilation is done by each module (eg fred.pas) having a header > file (eg fred.def) containing all the procedures, functions, types and > constants it wishes the rest of the world to know about. All the routines > in the header are 'external'. The modules all contain their own global > variables; if any need to share, this is done by access procedures, or > records shared via pointers. There is no > module/unit/import/export/interface/implementation system involved. The > modules are compiled individually, using #include (%include in Oregon) to You can also use (*$i Foo *) or (*$include "foo.pas" *) or (*$include <foo.pas> *). > pick up any external definitions and references required, and then linked. > I want to mechanically translate all these modules to gpc, so I'd prefer a > mechanism, if there is more than one available, that uses a structure as > similar as possible to the one we are currently using. The closest approximation to Oregon Pascal (as you describe it) which is currently possible with GNU Pascal is to use the "somewhat simpler GPC modules" described in `info -f gpc -n Extensions'. When `foo.pas' reads; Module Foo; Var x: Integer; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. Then your `foo.def' can be (* foo.def *) Var x: __external__ Integer; Procedure y; External; and $including `foo.def' into the main program and linking with `foo.o' will have the desired effect ... uh - sh** (sorry!) it does not work! :-( :-( While implementing other things I threw away this one. The reason is that this feature turned into a bug when using Extended Pascal Modules or UCSD/Borland Pascal Units. Okay, this "GPC specific module" is very close to yet another type of Module defined in the PXSC standard. The only difference is that PXSC wants the reserved word `global' in front of each declaration that is to be exported. That's certainly more reasonable than to export just everything (like GPC did until February 1997 or so). It is planned to implement these PXSC modules into GPC. So you can either wait until GPC will have PXSC modules and then use Module Foo; Global Var x: Integer; Global Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- (* foo.def *) Var x: __external__ Integer; Procedure y; External; --- Program Bar; (*$I foo.def *) ... or use UCSD/Borland-style Units Unit Foo; Interface Var x: Integer; Procedure y; Implementation Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar; uses Foo; ... or Extended Pascal Modules Module Foo Interface; Export FooStuff = ( x, y ); Var x: Integer; Procedure y; end. --- Module Foo Implementation; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar ( Input, Output, Whatever ); Import FooStuff; ... Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Hex output.
by Dr E. Buxbaum 07 Nov '97

07 Nov '97

> From: Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> > Subject: Re: Hex output. > To: richard.kerry(a)quantel.com, gpc(a)hut.fi > Date: Wed, 5 Nov 1997 14:46:11 +0100 (MET) > According to richard.kerry(a)quantel.com: > > > > Does gpc have a built-in mechanism for converting a number to hexadecimal, > > for use in write(ln) or just as a number to string conversion ? > > No(t yet;-). > > > Oregon Pascal uses a negative field width to denote hex output (which I > > believe is sometimes also used to denote left justification), and Vax > > Pascal has a built-in 'hex( num, width )'. > > I do not think it's good to use negative field widths for this purpose > (except, perhaps, for compatibility reasons). The Vax syntax, OTOH, > seems quite nice for me. > > Right now we are still trying to finish up gpc-2.1, but we might take > this into account for gpc-2.2. > > Hmm ... what about something like `NumBase ( base, num, width )' to > allow for arbitrary bases like in `2#101010'? May be that sort of thing should be left to libraries, rather than build into the run time system. The main advantage of the Wirth family of languages, compared to comitte languages like, say, Ada, has always been that their syntax was limited to the necessary. It is easy enough to write a little library to read and write hex numbers and to convert them to and from integers and strings. Copying any odd feature from any odd Pascal compiler out there will create something big and cumbersome, that nobody in the end will be able to handle anymore.

1 0

Paramstr(0) in ASM...
by The Kilobug Team 07 Nov '97

07 Nov '97

Hi! Do you know how to access the program directory (like Paramstr(0) does) from an ASM program? Thanx -- -= The Kilobug Team =- DOS Real&Protected mode programming. Home page: http://www.planetepc.fr/users/kilobug/ NEW site (beta, french obly): http://www.mygale.org/~kilobug/

1 0

Separate Compilation
by richard.kerry＠quantel.com 06 Nov '97

06 Nov '97

Hello, Could somebody please either : 1. Direct me to - or : 2. Send me - a comprehensive explanation of separate compilation using gpc, including examples that clearly show which bits are in different files and how the other bits pick up their definitions. And also including any alternate/non-standard/old-fashioned techniques that are still usable. I am working on a very large project, developed using Oregon Pascal. The separate compilation is done by each module (eg fred.pas) having a header file (eg fred.def) containing all the procedures, functions, types and constants it wishes the rest of the world to know about. All the routines in the header are 'external'. The modules all contain their own global variables; if any need to share, this is done by access procedures, or records shared via pointers. There is no module/unit/import/export/interface/implementation system involved. The modules are compiled individually, using #include (%include in Oregon) to pick up any external definitions and references required, and then linked. I want to mechanically translate all these modules to gpc, so I'd prefer a mechanism, if there is more than one available, that uses a structure as similar as possible to the one we are currently using. Thank you all in advance. Richard. PS. I apologize to anyone who has already seen this message. We've had an email problem and I suspect my previous attempt to send this went into hyperspace...

1 0

Re: BP PChar compatibility
by Frank Heckenbach 05 Nov '97

05 Nov '97

The African Chief wrote: > Procedure StrDispose ( Str : PChar ); > Begin > If ( Str <> Nil ) and ( Str^ <> Chr ( 0 ) ) > then begin > Free ( Str ); > Str := Nil; { doesn't seem to do anything !!!} > end; > End; {* StrDispose *} > > Obviously, the line "Str := Nil" does not actually set it > to Nil. I would have to make "Str" a VAR parameter to > do this, You seem to answer your own question here. Of course, Str, being a value parameter, will not be set to Nil, you couldn't expect this... ;-) > but I don't want to that (it will become incompatible > with BP for one). Yes, BP uses a value parameter, too, and doesn't try to set the pointer to Nil. So my question in the first place is, why do you want the pointer to be set to Nil? I think, with careful programming, you shoudln't ever access the value of a StrDispose'd pointer. (And if this could happen, setting it to Nil manually when necessary seems like a good way to solve the problem, in BP as well as in GPC.) > I have now done a hack to make sure > that "Str" points to nothing, by inserting this line; > Str^ := #0; > before the call to "Free ( Str )". Is there any reason why > I shouldn't do this? Well, it's, of course, perfectly legal to do this... but unfortunately it will not do what you expect it to do. The memory that's free'd is still undefined, whether you write something into it or not. Maybe the free() call doesn't usually overwrite the memory at once, but perhaps sometimes, e.g. when memory is returned to the system. Maybe (even probably) it behaves differently on different platforms, or with the next version of GPC, libc, the kernel or whatever, who knows? Therefore, I'd consider it bad practice to do what you intend to do, since it will tend to hide errors in the calling program, i.e. errors may not happen to show up during debugging, but will show in the delivered program, thanks to Murphy. I don't think that's what you want. I'd rather even change the routines to write *bad* values into the area so that errors will show up as early as possible. (Doing this is a bit difficult here, since you don't know the size of the memory block, so it might not be worth the effort here...) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: 2 suggestions about Units
by Frank Heckenbach 05 Nov '97

05 Nov '97

Hans Ecke wrote: > 1.) heredity and virtuall routines for units (yes, I mean objects!) I assume, you don't mean objects, but a behaviour like objects, right? > [...] > So what I would like to see would be: > > unit graph_fast(graph); I understand what you mean, but I'm not sure if it's realistic to make this feature. First of all, it would severly influence the unit concept, and I'm not sure if it couldn't even break something. Secondly, it's technically difficult. I don't know if you know about the technical details of objects (in BP or GPC), so perhaps the following might not be very meaningful to you, but anyway: a virtual method in an object is always called through a pointer which is stored in a table that every object type has (the so called VMT, virtual method table). So using virtual methods is a bit more inefficient than using normal procedures or static methods. If you want to do the same with procedures, you'd either have to use a pointer for *every* procedure (which is not tolerable in general), or you'd have to declare "virtual procedures". Well, this seems possible to do, but consider this: - Using such virtual procedures is (a little bit) inefficient, just like virtual methods. So, I guess, you would not want to use them in your super-fast graphics unit. - There is already another way to do it (which does not work for object methods), namely with procedural variables: unit graph_fast(graph); interface procedure this_putpixel(...) begin end; var putpixel:procedure(...) value this_putpixel; implementation procedure this_putpixel(...) begin end; ... unit log_graph(graph_fast); interface implementation var logfile:text; old_putpixel:procedure(...); procedure log_putpixel(x,y:integer); begin writeln(logfile,`Putpixel with parameters `,x,`,`,y); old_putpixel(x,y); end; begin old_putpixel:=putpixel; putpixel:=log_putpixel end. Basically, it does the same as a virtual procedure would do, only you have to program it explicity. (And, of course, some initalization is necessary at runtime, which isn't necessary for virtual methods...) This means, of course, that it's as inefficient as virtual methods, there's no way around it... - And, of course, there is always the option of making an object type out of the unit. This has the additional advantage of being able to have multiple instances (e.g. some virtual graphics screens, or remote screens on networked computers, or different windows in a window manager), but the additional disadvantage of requiring the implicit Self parameter which is again a little bit more inefficient. E.g., I'm planning such an approach for my Crt Replacement Tool, when I ever get to write it. Of course, for Crt-like I/O, efficiency is quite irrelevant today, for graphics, it isn't... > Maybe one could consider also Multi-heredity (is this a understandable > word?) Yes, it is. The common term is "multiple inheritance", BTW. > It would be just like Multi-heredity in C++. Well, we have discussed multiple inheritance (for objects, of course, not for units) around May-Jun, IIRC, (easy to find in the list archive by searching for this term), and we've come to the agreement (more or less ;-) that multiple inheritance implies a lof ot problems, and that most (if not all) of its goals can be reached by something called "interfaces". Interfaces were introduced in Java which builds on C++. Obviously, the Java inventors realized the problems inherent in multiple inheritance, and therefore invented this safer concept. With GPC, we want to take the short cut to the safe concept... :-) Basically, interfaces contain a list of declarations of virtual methods, but no implementations or fields. An interface can inherit from multiple interfaces, and an object type can inherit from multiple interfaces, but only from one object type. Parameters of interface type, and pointers to interface types are possible. Implementing interfaces into GPC will not be quite easy, but we have figured out most of the details by now, so there's hope that they will be realized until GPC 2.2 (no promises). > 2.) Making Libraries from units > I don't know if this task allready done. If so, ignore it. Today, units > make just object files. [...] It has been discussed, and is planned, but AFAIK, no concrete work or consideration has been done yet. BTW: I have set up a To-Do list for GPC at http://home.pages.de/~fjf/gpc-todo_toc.html There, you can see which features are planned, and which bugs are known (provided, you can decipher my sometimes quite crpytic entries... ;-) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: BP PChar compatibility
by The African Chief 05 Nov '97

05 Nov '97

On Wed, 5 Nov 1997 14:45:43 +0100 (MET) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> >> [...] Why does the following program behave differently >> under BP and GPC? >> [...] >> StrDispose(p1); >> if assigned(p1) then p2 := strnew(p1); >> Writeln(p2); {GPC writes the full string; BP writes "Fred"} > >If `StrDispose' does what the name promises, `writeln ( p2 )' should >produced *undefined* behaviour. The problem is that "StrDispose" first of all frees the memory associated with the pChar parameter, and then sets it to Nil - e.g., Procedure StrDispose ( Str : PChar ); Begin If ( Str <> Nil ) and ( Str^ <> Chr ( 0 ) ) then begin Free ( Str ); Str := Nil; { doesn't seem to do anything !!!} end; End; {* StrDispose *} Obviously, the line "Str := Nil" does not actually set it to Nil. I would have to make "Str" a VAR parameter to do this, but I don't want to that (it will become incompatible with BP for one). I have now done a hack to make sure that "Str" points to nothing, by inserting this line; Str^ := #0; before the call to "Free ( Str )". Is there any reason why I shouldn't do this? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: Hex output.
by Frank Heckenbach 05 Nov '97

05 Nov '97

richard.kerry(a)quantel.com wrote: > Does gpc have a built-in mechanism for converting a number to hexadecimal, > for use in write(ln) or just as a number to string conversion ? Not yet, AFAIK. > Oregon Pascal uses a negative field width to denote hex output (which I > believe is sometimes also used to denote left justification), Not in GPC (currently, anyway). I agree that both hex output (or more generally, output with arbitrary base) and left justification are useful features. Since I've just hacked almost all of the read and write routines, it would be no big deal to built them in the RTS, if wanted. The only question remaining is about the syntax. Obviously, not both can use negative field widths, and anyway, negative field withs are not very clear (neither to someone new, nor in comparison to other compilers that behave differently). Something that seems possible would be to use a second specifier (as real numbers have for the precision). Then, "write(42:5:16)" would produce " 2A". Now, should we use upper or lower case letters? Perhaps a compiler switch? For left justification, we could make another compiler switch, or indeed use negative field widths. The latter would make it easier to mix right and left justified output (which might be desirable). > and Vax > Pascal has a built-in 'hex( num, width )'. Such a function can, of course, be written in pure Pascal, if needed. (But it would duplicate some code that's similar in the RTS...) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

2 suggestions about Units
by Hans Ecke 05 Nov '97

05 Nov '97

Hi all! I want to (talk) about two possibilties to enhance flexibility of Units. Since I don't know EP modules (I think the syntax is to useless complicated) the following may or may not hold for EP modules. If the following is already discussed I would be happy to recieve a pointer to the result (maybe date to search in gpclist-archive) 1.) heredity and virtuall routines for units (yes, I mean objects!) Consider the following situation : You are programming the one&only fast graphics unit. It will do graphics with direct memoryaccess (you want to program only for your very own computer). So putpixel/getpixel, bar, line will be assembler routines. To get comfort(i.e. fonts) you want to use all the routines of the graph unit (Borland, port from bpcompat). Three problems: * The outtext,circel,...-routines of the graph-unit use putpixel inside (if this is true doesn't interest now). They won't use your putpixel but the original putpixel inside graph. * A program which uses your graphics unit has to include also the original graph unit in the "uses"-clause. The program isn't interested at all in the original unit, but only in your modified one, but has to include both. The program has to deal too with changed function-definitions by justifying the order of appearance in the uses-clause. * The new unit can't change types/constants and still be able to use the old ones. So what I would like to see would be: ///////////////////////////////////////////////// unit graph_fast(graph); interface ....if interface of the new unit changed, put it here implementation procedure putpixel(..) begin end; procedure line(...) begin end; ... begin inherited begin; end. ////////////////////////////////////////////////// Now a unit which does nothing new, but logs each putpixel() unit log_graph(graph_fast); interface implementation var logfile:text; procedure putpixel(x,y:integer); begin writeln(logfile,`Putpixel with parameters `,x,`,`,y); inherited putpixel(x,y); end; begin ..assigning logfile inherited begin; end. /////////////////////////////////////////////////// Main program program graph_test(input,output); uses log_graph; ....programming graphics, using fast putpixel + graph.tpu-comfort + logging facilities end. Maybe one could consider also Multi-heredity (is this a understandable word?) I mean something like this: unit graph_fast(logging,graph,print); It would be just like Multi-heredity in C++. 2.) Making Libraries from units I don't know if this task allready done. If so, ignore it. Today, units make just object files. Something like unit1; ...Some little utility functions the user don't has to interface know about implementation end. unit2 ...Your main unit. The user only has to work with this interface unit and even don't have to know the interface of uses unit1; unit1 implementation end. makes 2 object files. To compile a program using unit2 you need both. If you write units for someone else (s)he will not know about unit1 (the program only knows about unit2) and maybe will delete the file. To make it more distributable we need a mechanism to concentrate all code and interface from all the forefathers of a unit (or a subset of them) into one object (or librarie) file and have the commands for it inside the source (pascal-philosophy) I hope I was clear enough, write if not, I will correct then. Hans

1 0

BP PChar compatibility
by The African Chief 05 Nov '97

05 Nov '97

Hiya all It seems that there is a difference between the way that BP and GPC handle pChar parameters. In BP, pChars always seem to be passed by reference. In GPC, this is often the case, but is it always so? Why does the following program behave differently under BP and GPC? PROGRAM TestStr; {$ifdef ver70} USES STRINGS; {$else ver70} USES SYSTEM, STRINGS; {$X+} {$endif ver70} Var p1,p2:pchar; s:string; Begin s := 'Fred is a good boy and a good father and uncle'+#0; p1 := StrNew (@s[1]); Writeln(p1); StrDispose(p1); if assigned(p1) then p2 := strnew(p1); Writeln(p2); {GPC writes the full string; BP writes "Fred"} StrDispose(p2); StrDispose(p2); {should cause a runtime error - but doesn't under GPC} End. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro 4.01 for Win16 and Win32: http://www.simtel.net/pub/simtelnet/win3/install/chief401.zip

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