Recent

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

MarkMLl

  • Hero Member
  • *****
  • Posts: 2712
Re: initialization of array of pointers
« Reply #30 on: April 07, 2021, 08:50:48 am »
While 1 is a constant "a" is not, and 1 was just its initial value.

What's more a could /potentially/ be removed by optimisation if it weren't used at runtime, since the only important thing is that the compile-time parse tree which gives it its value is propagated.

In any event, nothing's going to change and at least we've got a robust error message indicating that the compiler's unhappy about what it's asked to do.

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

PascalDragon

  • Hero Member
  • *****
  • Posts: 3064
  • Compiler Developer
Re: initialization of array of pointers
« Reply #31 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: 2712
Re: initialization of array of pointers
« Reply #32 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and 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: 2368
Re: initialization of array of pointers
« Reply #33 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 on Windows 7 64bit.

ASBzone

  • Hero Member
  • *****
  • Posts: 613
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: initialization of array of pointers
« Reply #34 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.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

 

TinyPortal © 2005-2018