Hello,
is there a way that dynamic arrays can be created (using schemata) which are GLOBAL, i.e. not accessible in the sole main program, but also in all functions and procedures included in it? For instance this little piece of code gives me this error:
espon.pas: In procedure `Merce': espon.pas:50: undeclared identifier `Vett' (first use in this routine) espon.pas:50: (Each undeclared identifier is reported only once espon.pas:50: for each routine it appears in.) espon.pas:50: subscripted object is not an array or string
the code follows:
program skifo;
type
TVecDob (Size: Integer) = array [ 1 .. Size ] of double; PVecDouble = ^TVecDob;
Function Power ( base: real; espon: integer ): double;
var
i, j: integer;
buff: real;
begin
buff := base;
for i :=1 to espon - 1 do begin
buff := buff * base;
end;
result := buff;
end;
Procedure merce;
var
i,j: integer;
begin
for i := 1 to 10 do begin
writeln (' vett ', i, '=', vett [i] );
end;
end;
var
nelem, i, j : integer;
begin
nelem := 10;
var vett: TVecDob ( nelem );
for i := 1 to 10 do begin
vett [i] := 1+0.1*i;
end;
merce;
end.
Thank you very much
Silvio
On 15 Mar 2002 at 17:48, Silvio a Beccara wrote:
Hello,
is there a way that dynamic arrays can be created (using schemata) which are GLOBAL, i.e. not accessible in the sole main program, but also in all functions and procedures included in it? For instance this little piece of code gives me this error:
You obviously come from a C background. First, your program is illegal (you cannot declare variables within a "begin .. end" block. Secondly, the variable "vett" is used before being declared. If you want it to be visible throughout the program, you should declare it at the top of the program (before you start defining your procedures and functions).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Attached you find the GPC 2.1 RC 3 test results for all the Debian GNU/Linux architectures.
Matthias Klose wrote:
Attached you find the GPC 2.1 RC 3 test results for all the Debian GNU/Linux architectures.
Thanks. However because of the (incorrect IMHO) "Internal compiler error" messages in gcc-2.95.4 (as discussed by private mail), the results are still rather spurious.
I'm changing GPC to avoid these messages by using fatal() only for real internal compiler errors now (though I'm not sure if it's really meant this way).
If no new bugs reports appear here for some more days (how long can you wait? ;-), I'll make a RC4 including this change, and I hope you can test it again.
Frank
Prof Abimbola Olowofoyeku wrote:
On 15 Mar 2002 at 17:48, Silvio a Beccara wrote:
Hello,
is there a way that dynamic arrays can be created (using schemata) which are GLOBAL, i.e. not accessible in the sole main program, but also in all functions and procedures included in it? For instance this little piece of code gives me this error:
You obviously come from a C background. First, your program is illegal (you cannot declare variables within a "begin .. end" block.
Well, actually you can in GPC, but that's a non-standard extension.
Secondly, the variable "vett" is used before being declared. If you want it to be visible throughout the program, you should declare it at the top of the program (before you start defining your procedures and functions).
Indeed. That's one problem -- because of the "declare before use" rule (which is the same in C BTW), variables declared in the statement part are never visible to subroutines.
The other problem is that GPC in fact does not support global variables of non-constant size. (This is planned, but since it will have to be implemented using a pointer internally, it's not completely trivial to do.)
The solution to both problems is the same: Declare a pointer variable (before the subroutine), and allocate it with `New' (e.g., `New (Vett, nelem)'). Of course, you then have to dereference it explicitly with `^' in every usage. Alternatively, you could pass it as a parameter to the procedure, like:
Procedure merce (var Vett: TVecDob);
[...]
merce (Vett^);
Then you only need `^' in the main program, not in the procedure. (Instead of a `var' parameter, you could also use `const' or `protected var', or even a value parameter if you want it to be copied. This works because the size is known when the procedure is called.)
Frank
Frank: thank you for your explanations.
Coming from Kylix, I've never used vectors with pointers before. Could you give me an example routine for declaring and referencing-dereferencing this objects? I would need, besides vectors, also matrices up to 3 (M x N x P elements) dimensions.
Also, could I simply declare a schema in the main program, and then call all procedures from it with a normal statement (e.g. merce (Vett) ), like in the GPC demo program about schemata?
thank you, regards
Silvio
The solution to both problems is the same: Declare a pointer variable (before the subroutine), and allocate it with `New' (e.g., `New (Vett, nelem)'). Of course, you then have to dereference it explicitly with `^' in every usage. Alternatively, you could pass it as a parameter to the procedure, like:
Procedure merce (var Vett: TVecDob);
Silvio a Beccara wrote:
Frank: thank you for your explanations.
Coming from Kylix, I've never used vectors with pointers before. Could you give me an example routine for declaring and referencing-dereferencing this objects? I would need, besides vectors, also matrices up to 3 (M x N x P elements) dimensions.
Roughly (untested):
type PMatrix = ^TMatrix; TMatrix (m, n, p: Integer) = array [1 .. m, 1 .. n, 1 .. p] of Real;
var Matrix: PMatrix;
[...]
New (Matrix, m0, n0, p0); Matrix^[i, j, k] := 4.2e1; Dispose (Matrix);
(BTW, for such things please use the latest version of GPC. I've fixed some bugs regarding schemata with multiple discriminants recently.)
Also, could I simply declare a schema in the main program, and then call all procedures from it with a normal statement (e.g. merce (Vett) ), like in the GPC demo program about schemata?
Yes. There's only one technical difference: Such variables are placed on the stack, not the heap. If they are large (say, more than a few MB in total), you might run into conflicts with your system's stack limits.
Frank