According to Jakob Heinemann:
I'm looking at GPC to decide wether or not to use it to port a quit large application from VMS to Unix.
[...]
According to the documentation the GPI-mechanism is not as stable as it should be. but what is the actual problem? what are the limitations? the problem of unsized strings and GPI import? (I get a warning that there are incompatible pointers when calling an imported function with a varying string.) is there som work beeing done to fix it?
Some constructs do not survive transport through a GPI file. The most important thing is probably the generic String Schema type (without specified length). This will be fixed next. There are also some problems concerning file and object types.
As a workaround, you can (*$include *) the Interface Modules into your source (above the `Program' headline). Then you can compile the Implementation Modules separately and link everything together. This mechanism is considered stable.
The GPI problem is annoying, but it is solved in theory. What remains is a bulk of work to determine which parts of which structure must be stored in the GPI file.
Other questions that I also came up with are: Calling functions in C, is easy, just put a C; as a declaration af the body. How about calling functions in ADA (i.e. Gnat)?
You can import any function written in any language by writing a Pascal Procedure/Function head for it. (This does survive transport through a GPI file.)
The `C' keyword is named in a little misleading way. It means: "Import that function and assume that its name is in lowercase." - independent of the question what compiler produced that function. For mixed case you can use the `AsmName' directive:
Type Pointer = ^Void;
Function XEventsQueued ( Display: Pointer; Mode: Integer ): Integer; AsmName 'XEventsQueued';
The other way around, other languages calling functions written in Pascal?
No problem if the other language supports that. For example, to use a
Procedure FooBar ( x: Integer; Var y: Char );
from a C program, import it as
extern void Foobar ( int x, char *y );
Note that the First Letter Of The Pascal Name Is Capitalized and does not depend on how you write the name in your Pascal source. (The same holds when debugging a program written in GNU Pascal: You have to specify all symbols with one capital letter.)
The code uses lots of varying length strings written partly as schemas, and partly as some sort of conformant arrays in parameter lists. A piece fo code may look like this:
Var text_str : varying (. len .) of char ;
procedure testproc ( str : varying (.len .) of char ); var i : integer ; begin for i :=3D 1 to len do something(i,str); end ;
This should translate to
Var text_str : string;
procedure testproc ( str : string ); var i : integer ; begin for i :=3D 1 to length(str) do something(i,str); end ;
Yes, this should work. The problem to transport a `String' through a GPI file is worked on, but for the moment you can include the Interfaces as a workaround (see above).
But how about the vax statement for issuing variable amount of arguments? Vax-pascal:
procedure test_pro ( var arg1 : integer; [list] therest : integer) ; var cnt : integer ; begin arg1:=3D 0 ; for cnt :=3D 1 to argument_list_length (therest) do arg1 :=3D arg1 + argument(therest, cnt): end;
Is there a construct for this in GPC? (in that case I=B4m sorry but I haven=B4t found it in the manual)
GNU Pascal has an ellipsis parameter for variable argument lists:
Procedure Test_Pro ( Var arg1: Integer; ... );
but at the moment we do not provide a way to access those arguments. (However this feature is useful to work with C functions having variable argument lists.)
Since VAX Pascal seems to provide such a mechanism it could be a good idea to implement that scheme into GPC, too, instead of inventing a new method to achive this functionality. It would be nice if you could tell me more about this - and perhaps about other nice features of VAX Pascal which you would like to see in GNU Pascal. It might be that they are relatively easy to implement - in that case we would probably do it, and you can save a lot of work porting your application.
If all additional parameters have the same type, you can use either conformant arrays or "open arrays" (according to Borland Pascal) to pass them:
Procedure Test ( Var arg1: Integer; Var therest: array of Integer );
Then you can pass any array of Integers as the actual parameter; in the function body the lower bound of the array is assumed to be zero.
I don=B4t think I'm on the subscriberlist so please post your reply directly to me aswell.
I am doing so, so you should get this mail twice if you are on the list.
(I've tried to subscribe , but I'havent hear anything...)
The list is maintained manually, so delays are possible. If the delay lasts too long, please complain to gpc-request@hut.fi.
Even if you are not on the list, you can read it via the list archives on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/, updated daily. You can also get them through the GNU Pascal WWW home page, http://home.pages.de/~GNU-Pascal/.
Thank you guys, Gnu Pascal's great, but I still miss some important consepts from the extended pascal definition. (Schemas and module integrity...) Hope that all the stuff will be there some day, right now I feel it is not so safe that it will suit our need for this project, but perhaps in the future..
I am myself porting a large project (104 modules, 102k lines :-P) from Borland Pascal (DOS) to GNU Pascal (DOS, OS/2, UNIX, ...), so there is hope that GNU Pascal will become more reliable not too far in the future. Please be patient - or offer your help!
Thanks for your interest,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]