Gpc November 1997

gpc@gnu.de

32 participants
113 discussions

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

Re: Problem
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to sam.littlewood(a)quantel.com: > > Using gpc-971001, The code below fails to compile with errors ' prior > parameter's size depends on ...'': |-O Gnuuuaaaaah! 8-( This was one of the most weird errors in earlier versions of GPC, and now IT'S BACK ... =8-O > Is this a known problem, and how might I go about fixing it? Well ... it's known - and solved - for other situations such as "ordinary" undiscriminated schemata as reference parameters. I will try to fix it until the next beta ... Thanks for the report! 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 Peter Gerwinski 05 Nov '97

05 Nov '97

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'? 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: BP PChar compatibility
by Peter Gerwinski 05 Nov '97

05 Nov '97

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. Since BP writes "Fred" instead of producing a runtime error, BP obviously passes `p1' by *value* just like GPC. Since `p1' is a *pointer* to the actual chars, the *string* is always passed by reference - both in BP and in GPC. > StrDispose(p2); > StrDispose(p2); {should cause a runtime error - but doesn't > under GPC} This is incorrect, indeed. After the first `Dispose', the pointer should have an undefined value, so the second `Dispose' normally should crash. But in fact is is also correct "undefined" behaviour simply to ignore the second `Dispose' ... 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

Hex output.
by richard.kerry＠quantel.com 05 Nov '97

05 Nov '97

Hello, 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 ? 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 )'. Thank you in advance .. Richard.

1 0

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