Recent

Author Topic: initialization of array of pointers  (Read 5260 times)

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: initialization of array of pointers
« Reply #30 on: April 07, 2021, 09:24:21 am »
I don't think this is the only way the compiler has. If px was not initialized with a value, it is nil by default if declared as a global variable, or it holds some random value if declared as a local variable. The compiler could issue a hint or warning for the first case, and error for the second case.
The problem is as follows, for the compiler to use the value assigned to px or any pointer for that matter, it has to dereference px at compile time.  dereferencing a pointer is a runtime operation, not a compile time one.

No, the compiler does not need to do any dereferentiation for this.

Consider the following code:

Code: Pascal  [Select][+][-]
  1. var
  2.   x: Real;
  3. const
  4.   px: PReal = @x;
  5.   arr: array[0..1] of PReal = (@x, px);

Right now the compiler treats px like a variable and it doesn't know about its value. However if the compiler would treat typed constants more like their untyped counter parts(*) then it would know the value of px at compiletime and thus would be able to propagate that to the initialization of arr. Any changes at runtime to px would not be reflected in arr however as this constant propagation would only happen at compiletime.

(*) Right now the initialiser value (here the @x) is a completely separate symbol (tabstractnormalvarsym.defaultconstsym), to achieve the constant propagation the compiler would instead need to store a constant node (in this case a tpointerconstnode) with px.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: initialization of array of pointers
« Reply #31 on: April 07, 2021, 09:36:32 am »
No, the compiler does not need to do any dereferentiation for this.
...
if the compiler would treat typed constants more like their untyped counter parts(*) then it would know the value of px at compiletime and thus would be able to propagate that to the initialization of arr.

That's the important thing. Note that I (for one) am not saying "this should be fixed": after all there's got to be limits to feeping creaturitis.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: initialization of array of pointers
« Reply #32 on: April 07, 2021, 05:12:38 pm »
That it!  this is going backwards instead of forward.  I'm leaving it alone.

My consolation prize is: it will never be implemented, thank god for small favors. :)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: initialization of array of pointers
« Reply #33 on: April 14, 2021, 06:00:13 pm »
It's not confusing because in one case it's a constant (@x) and in the other it's a variable (px^). 

The original code was

Code: Pascal  [Select][+][-]
  1.         {arr: ArrayOfPReal = (@x, @x); ok}
  2.         arr: ArrayOfPReal = (@x, px); {Illegal expression}
  3.  

Now it might be that somebody has moved the goalposts, but I read the failing expression as two pointers: nobody was trying to dereference anything.

However the bottom line is that an address that can't be resolved by the compiler and if necessary relocated by the linker can't be used as an initialiser.

MarkMLl

Actually, the first item in that expression is obviously a pointer constant.  The second item in that expression is a variable of a pointer.   You happen to know it is the variable of a pointer, because you've looked at that the type is from earlier statements.

But if someone gave you ONLY that single line with the expression, you'd have to conclude that it shows one pointer constant, and one variable of some type (as yet to be determined, with no other context present).
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

 

TinyPortal © 2005-2018