Gpc

gpc@gnu.de

5400 discussions

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: > Frank Heckenbach wrote: >> >> begin >> bla:=xx.methodname; >> end; > > So IIUC, the difference to Markus' way is that here the procedural > variable also contains the object, while there it only points to the > method, and can be applied to any object (of matching type), right? Yes, though object-instance might be a better phrasing. It works though with uninitialised objects too as long as you don't actually "use" (dereference) self: {$mode delphi} type tmyobject = class function bla ( x: integer):integer; end; tmethodvar = function (x:integer):Integer of object; function tmyobject.bla(x:integer):Integer; begin writeln(x, ' ', PtrInt(self)); // ptrint is guaranteed pointer size compat end; var x : TMyobject; y : tMethodVar; begin x:=nil; // if you can detect uninitialised vars, this is not necessary. y:=x.bla; y(5); end. will write 5 0 I'm a bit worried that this syntax is a bit focused on object types that are already (implicitely) a pointer, like Delphi. If this is possible with (one of ) your object models, better warn if you try to assign a methodvar to a method of an object that is on the stack instead of on the heap.

2 4

Re: Hacking "method variables"
by Frank Heckenbach 09 Jun '06

09 Jun '06

Markus Gerwinski wrote: > I just did a little experiment. The full source code is attached, but what I'm > doing is, in brief, the following: > > - Declaring an object type tTestObj with a method `foo', > - giving this method an attribute name, > - declaring (in the same source!) an external-declared function with the same > attribute name and a pointer (for the object) as an additional parameter, > - assigning this method to a procedure variable, > - calling the variable with a pTestObj as a parameter. > > Result: It works! :-) The method is executed as if it was "correctly" called > via tTestObj.foo, including access to private fields of the object. > > Question: Is this supposed to work? I.e. can I rely on this feature remaining > in GPC? Or is it rather looked upon as a bug, so I have to expect it'll be > removed some day? I'd consider it perhaps a misfeature, but I think it will keep working, as long as you use explicit linker names (as you do), and take care of the parameter list ("Self" last, in contrast to BP where it's first, no difference in the example). However, actually "Self" is a reference parameter of object type, not a value parameter ob object pointer type. Though both are implemented the same, and this is also unlikely to change, the example can easily be changed to avoid depending on this. > I'd like to use it as a feature, since it provides me with a way to assign > methods to procedure/function variables, something I've been missing in GPC so > far. OTOH, I would, of course, even prefer to have real, "syntax-approved" Yes, the first problem is to define a syntax. I think there might have been some suggestions before, but nothing concrete so far AFAIR. Do other dialects have something like that, if so which syntax? > method variables that also take into account polymorphy and the fact that > methods might be overridden. Here's an alternative: gFoo:= tFooFunc (@tTestObj.foo); This avoids the linker name tricks, but requires a type-cast. It has the advantage that it works with (non-)overridden methods, i.e. you can put in a derived type of tTestObj, whether in inherits tTestObj.foo or defines its own foo. For a compiler-implemented solution, this issue would also be easily solved. For polymorphy (i.e., virtual) methods, the problem is that a procedural variable needs a constant address. One way to solve it is to write a wrapper routine that does the actual virtual call. This solution (see below) doesn't even require a type-cast or other dirty stuff. It also works for non-virtual methods, of course, if you're willing to accept the small wrapper overhead (which seems inevitable for virtual methods, but can be avoided for non-virtual methods, as in your example). For a compiler-implemented solution, polymorphy would also be an issue, and AFAICS, the compiler would need to emit such a wrapper routine automatically then. That might not be too difficult per se (just some work to do ...), but the important question is, when and where to emit such wrappers (looks a bit like the C++ template problems). We could emit one on each usage, at the danger of emitting the same one several times (might even be in different units). Or emit one for each virtual method, at the danger of emitting some (often many) that aren't used at all. Of course, it's not a huge issue (just a few bytes per routine), but since a manual solution is available, I'd first wonder if the effort is justified for a feature that might not be used all that often ... Program Test; type pTestObj = ^tTestObj; tTestObj = object public Constructor init ( aBar: integer ); Procedure foo; virtual; private fBar: integer; end (* tTestObj *); p2 = ^t2; t2 = object (tTestObj) Procedure foo; virtual; end (* tTestObj *); tFooFunc = Procedure ( var obj: tTestObj ); var g1, g2: pTestObj; gFoo: tFooFunc; Constructor tTestObj.init ( aBar: integer ); begin (* tTestObj.init *) fBar:= aBar; end (* tTestObj.init *); Procedure tTestObj.foo; begin (* tTestObj.foo *) writeln ( 'I''m one.' ); end (* tTestObj.foo *); Procedure t2.foo; begin (* tTestObj.foo *) writeln ( 'Me two.' ); end (* tTestObj.foo *); Procedure FooWrapper ( var obj: tTestObj ); begin obj.foo end; begin g1 := new ( pTestObj, init ( 42 ) ); g2 := new ( p2, init ( 42 ) ); gFoo:= FooWrapper; gFoo ( g1^ ); gFoo ( g2^ ); end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 3

Re: Hacking "method variables"
by Markus Gerwinski 09 Jun '06

09 Jun '06

Peter N Lewis wrote: > >OTOH, I would, of course, even prefer to have real, "syntax-approved" > >method variables that also take into account polymorphy and the fact that > >methods might be overridden. > > I'm afraid I can't understand the point of this, why not just use an > indirecting procedure: > > Remove the attribute names, and define > > Procedure testObjFoo ( obj: pointer ); > begin > pTestObj(obj)^.foo; > end; That's basically what I've been doing for a couple of years now, and as far as only my own code is affected, I find it a bit annoying, but acceptable. However... well, see below. > No need to rely on the compiler implementation of anything. > > Sure there is a negligible drop in efficiency, and you have to write > a duplicate for any method you want to use a a procedural variable, > but these hardly seem like big problems unless you have very specific > requirements that make them big problems...? The point is: I'm writing an API where I'd like to give the application developer the possibility to pass a method as an initialization parameter to the constructors of some objects. For example to an intermediate wrapper that turns rows of an SQL result set into objects and vice versa.

1 0

Re: Hacking "method variables"
by Frank Heckenbach 09 Jun '06

09 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: > Yes, the first problem is to define a syntax. I think there might > have been some suggestions before, but nothing concrete so far > AFAIR. Do other dialects have something like that, if so which > syntax? Delphi syntax type tbla = procedure bla(param1,param2,param3:integer) of object; Only allowed to assign methods. (classes model) Internally such beast is a record ("TMethod") with two fields. "code" and "data". Code contains a ptr to the function, data self or nil. (the latter in case of "class" (static) methods) Assignment is simple var bla: tbla; begin bla:=xx.methodname; end;

1 1

Bison-2.2
by Frank Heckenbach 07 Jun '06

07 Jun '06

Bison version 2.2 has been released. To make GPC work with it requires some minor changes. Patch attached, details in the ChangeLog entry. Bison 2.2 also has a new feature: : * %require "VERSION" : This specifies that the grammar file depends on features implemented : in Bison version VERSION or higher. Since we actively use some newer (2.0 and/or 2.1) features of Bison, we actually should use this check, to avoid users even trying with older Bisons which cannot work. OTOH, since the check is new in 2.2, we can't "%require 2.1", so by using this check we would needlessly (ATM) require Bison 2.2. What should we do? Perhaps wait until 2.2 is more widespread, then require it? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 5

Re: gpc installation using Xcode
by Adriaan van Os 31 May '06

31 May '06

Forwarding the private reply: Hi Adriaan, Thanks so much for your help - the program now works fine. I tried installing the compiler a long time ago, before the Xcode environment existed, and could never get anywhere with it, but it looks absolutely great now it works with Xcode - easy enough for me to use! Thanks again, Graham > Graham Carter wrote: > >> Examples/SillyBalls/Sources/MainProgram.pas >> gpc1: error: invalid option `dynamic-no-pic' > > I still have to update the GPC Xcode Kit, but you can apply the > following change to make it work. For IntelMac, please double-click > on the "Debug" Target. Then, in the Build Settings pane, change > > GPC_CODESTYLE = -mdynamic-no-pic > > to > > GPC_CODESTYLE = > > The -mdynamic-no-pic option is not (yet) supported for IntelMac. > Same procedure for the "Deploy" Target. > > The best place to ask Xcode specific questions is really the > MacPascal mailing list <http://www.pascal-central.com/maillist.html>. > > Regards, > > Adriaan van Os >

1 0

gpc installation using Xcode
by Graham Carter 31 May '06

31 May '06

Hi, I've just installed gpc, the associated Pascal interfaces and the Xcode software on my Intel Mac. I've configured Xcode in the way suggested and just tried to compile one of the sample programs. It compiles ok but falls over with this error: Building target “Debug” of project “SillyBalls” with configuration “Default” — (1 error) [lots of stuff deleted] 1.1/Examples/GUI Examples/SillyBalls/build/Debug/Objects/ -I . -I / Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/units -I / Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/ Sources/ --unit-path=/Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/Sources/ -E -H /Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/Sources/MainProgram.pas gpc1: error: invalid option `dynamic-no-pic' make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 Build failed (1 error) Can anyone more knowledgeable than me (that would be most people!) suggest what I might need to do? Sorry to be a pain, I know the answer is probably obvious to everyone on this group but this is my first step into programming a Mac (or using a unix-like environment). Thanks in advance, Graham Carter

2 1

Xcode 2.3
by lanceboyle＠qwest.net 26 May '06

26 May '06

Should GPC folks upgrade to Xcode 2.3? What are the issues, if any? Jerry

2 3

modules and scope
by Ram Seshadri 18 May '06

18 May '06

Further to my previous e-mail I have a question relating to the use of modules and scope of variables declared in module being 'seen' by other modules. The thing is I have variables in one module that I want to be able to seen by other modules. I thought as long as I export the variables from the module it should be fine but it seems not to work all that well as on compiling I get undefined reference errors. I am a newbie to pascal so don't fully understand the inner workings so help would be appreciated.

2 1

.var files and include files
by Ram Seshadri 16 May '06

16 May '06

Does the latest version of the GNU compiler support the use of include files to declare procedures and functions. When i put them in include files I get compiler errors of multiple declarations. Help would be much appreciated. Ram

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