Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
Adam Naumowicz wrote:
Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
It seems to me that this is a bug. It is said somewhere that a const parameter in a function can be either passed by value or by reference, for optimisation purposes, and this is checked in the programs cstpar1.pas / cstpar2.pas of the test suite. Now both a value parameter or a var parameter is OK, only const complains.
Maurice
Maurice Lombardi wrote:
Adam Naumowicz wrote:
Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
It seems to me that this is a bug. It is said somewhere that a const parameter in a function can be either passed by value or by reference, for optimisation purposes, and this is checked in the programs cstpar1.pas / cstpar2.pas of the test suite. Now both a value parameter or a var parameter is OK, only const complains.
I am new here, but an old hand at Pascal and Pascal implementation.
Will somebody please explain why this 'const' extension exists at all? A non VAR parameter is always passed by value, so the original cannot be modified. Thus I see absolutely no purpose to it.
On 13 Oct 01, at 18:00, CBFalconer wrote:
[...]
I am new here, but an old hand at Pascal and Pascal implementation.
Will somebody please explain why this 'const' extension exists at all? A non VAR parameter is always passed by value, so the original cannot be modified. Thus I see absolutely no purpose to it.
There is a point. 'const' parameters are a Borland extension that allows you to pass a parameter by reference, but in a read only format. It can help with stack overflows, performance, etc. GPC has had some issues with const parameters in the past, and I am sure that they are not all sorted out yet. This may be one of them.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 13 Oct 01, at 18:00, CBFalconer wrote:
[...]
I am new here, but an old hand at Pascal and Pascal implementation.
Will somebody please explain why this 'const' extension exists at all? A non VAR parameter is always passed by value, so the original cannot be modified. Thus I see absolutely no purpose to it.
There is a point. 'const' parameters are a Borland extension that allows you to pass a parameter by reference, but in a read only format. It can help with stack overflows, performance, etc. GPC has had some issues with const parameters in the past, and I am sure that they are not all sorted out yet. This may be one of them.
I see. Seems like the wrong way, to me. One more Borland attempt to C-ify the language.
My approach (I think) would be to check the usage within the function block, and if not modified and the size is above the size of a pointer, convert the usage to a VAR. This could be done without fixups if the normal access to a large parameter was via a local (and programmer invisible) pointer. Except that that won't work unless the practice for large parameters is to copy them into local storage, rather than have the caller copy them onto the stack. This in turn means conformant arrays have to be VAR (which I vaguely recall is already the specification) unless there is some sort of alloca equivalent available internally. It all messes up the function entry code.
CBFalconer wrote:
Prof Abimbola Olowofoyeku wrote:
On 13 Oct 01, at 18:00, CBFalconer wrote:
[...]
I am new here, but an old hand at Pascal and Pascal implementation.
Will somebody please explain why this 'const' extension exists at all? A non VAR parameter is always passed by value, so the original cannot be modified.
It's not about whether the original (i.e., the actual parameter), but rather the formal parameter in the routine can be modified.
Thus I see absolutely no purpose to it.
There is a point. 'const' parameters are a Borland extension that allows you to pass a parameter by reference, but in a read only format.
In fact, passing by reference is *not* guaranteed (just like it isn't in BP).
I see. Seems like the wrong way, to me. One more Borland attempt to C-ify the language.
Maybe, but OTOH, Extended Pascal has something very similar, viz `protected' and `protected var' parameters. The only difference is that passing by value or reference, respectively, is guaranteed there.
My approach (I think) would be to check the usage within the function block, and if not modified and the size is above the size of a pointer, convert the usage to a VAR.
That's not quite the same. By declaring a parameter `protected' or `const', you are telling the compiler that you don't want to modify it, and if you ever do it accidentally, it should tell you about it, rather than just changing its way of passing.
There's another problem: In a module (or unit) interface, the compiler doesn't know the implementation code yet. It therefore would always have to assume it might be modified, and could never optimize it by passing it by reference.
I suggest to use `protected [var]' if
- you want to be standard-conformant,
- you need to interface a C routine (ironically, though BP is usually closer to C, its `const' can't be used there because you can't be sure if it will pass the variable by value or reference, cf. the comments in the beginning of gpc.pas), or
- it makes a real difference (apart from performance) whether is it passed by value or reference (this can happen if the actual parameter is modified from the routine which is, of course, bad practice, and should be avoided generally, anyway).
In other cases, I usually use `const' to let the compiler pick the most efficient way of passing (e.g., for a small record, passing by value might be more efficient, but when I add a few fields later, it will be more efficient to pass it by reference; I don't want to have to bother about that).
This in turn means conformant arrays have to be VAR (which I vaguely recall is already the specification)
ISO 7185, 6.6.3.6 e) mentions both value and variable conformant-array-specification.
Frank
Maurice Lombardi wrote:
either passed by value or by reference, for optimisation purposes, and this is checked in the programs cstpar1.pas / cstpar2.pas of the test suite. Now both a value parameter or a var parameter is OK, only const complains.
I am new here, but an old hand at Pascal and Pascal implementation.
Will somebody please explain why this 'const' extension exists at all? A non VAR parameter is always passed by value, so the original cannot be modified. Thus I see absolutely no purpose to it.
For performance reasons I think, specially with larger structures.
Newer Delphi's also have an OUT extension. (writeonly) to complete the number of possibilities. The reasons for that are afaik related to the Windows Api.
On Sat, 13 Oct 2001, Adam Naumowicz wrote:
var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
It's more of an anoyance than a problem. Just omit "const". The following program illustrates there's no side effect: (note: changed "at" to "ax" because "at" is in use.
program foo;
var a:array[0..10] of integer; b,c : integer;
function ax( index:integer):integer; begin ax:=a[index]; index := 5; end;
begin b:=1; c:=ax(b); writeln(b); {writes 1} end.
You can also use c:=a[1];
russ
Adam Naumowicz wrote:
Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
My compiler fails on the `.......' which is not a valid start of a Pascal program.
In other words: Please post complete test programs!
I'm just back from a 3 days conference, and found more than 100 mails waiting for me, so I really don't feel like completing such code fragments, sorry.
Frank
On Sun, 14 Oct 2001, Frank Heckenbach wrote:
Adam Naumowicz wrote:
Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
My compiler fails on the `.......' which is not a valid start of a Pascal program.
In other words: Please post complete test programs!
I'm just back from a 3 days conference, and found more than 100 mails waiting for me, so I really don't feel like completing such code fragments, sorry.
Sorry for that. I know the filling quite well, too ;-) This test was so straightforward that I was too lazy to form a program from it, but of course I'll send complete test programs in future. I hope the next time will be quite soon as I'm still fighting to catch the memory leak that started to occur with latest GPC versions. Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
Adam Naumowicz wrote:
On Sun, 14 Oct 2001, Frank Heckenbach wrote:
Adam Naumowicz wrote:
Hello, I would like to know what is the reason why GPC complains about type mismatch compiling lines like below: ....... var a:array[0..10] of integer;
function at(const index:integer):integer; begin at:=a[index]; end; ....... It seems to me, that there is a too rigid type checking in this matter. Why are constants not allowed here ?
My compiler fails on the `.......' which is not a valid start of a Pascal program.
In other words: Please post complete test programs!
I'm just back from a 3 days conference, and found more than 100 mails waiting for me, so I really don't feel like completing such code fragments, sorry.
Sorry for that. I know the filling quite well, too ;-) This test was so straightforward that I was too lazy to form a program from it, but of course I'll send complete test programs in future.
The problem turned out quite a bit more extensive, but fortunately easy to fix:
* 20011015: wrong type mismatches with `const' and `protected' parameters used as array indexes, as case selectors, in writing to typed files, in `Include', `Exclude', `in', in set assignments, or in file seeks (adam3[a-v].pas, chief31.pas)
Frank
-
Adam Naumowicz -
CBFalconer -
Frank Heckenbach -
marcov＠stack.nl -
Maurice Lombardi -
Prof Abimbola Olowofoyeku -
Russell Whitaker