Re: pointer confusion

On 12/6/22 15:40, ToddAndMargo via perl6-users wrote:
> On 12/5/22 16:35, Ralph Mellor wrote:
>> On Mon, Dec 5, 2022 at 10:20 PM ToddAndMargo via perl6-users
>> <[email protected]> wrote:
>>>
>>>> use NativeCall;
>>>> my Pointer $foo .= new: 42;
>>>> say $foo;   # NativeCall::Types::Pointer<0x2a>
>>>> print $foo; # NativeCall::Types::Pointer<5895604297984>
>>
>> ----
>>
>> `say` concatenates the `.gist`s of each of its arguments. In this case
>> `say` only has one argument, `$foo`, which contains a `Pointer`.
>>
>> The `.gist` of a `Pointer` is a concatenation of:
>>
>> * The full type name (`NativeCall::Types::Pointer`)
>>
>> and
>>
>> * `<...>` enclosing the pointer's value (the address it represents)
>>    in HEXADECIMAL literal form.
>>
>> ----
>>
>> `print` concatenates the `.Str`s of each of its arguments. In this case
>> `print` only has one argument, again `$foo` which contains a `Pointer`.
>>
>> The `.Str` of a `Pointer` is a concatenation of:
>>
>> * The full type name (`NativeCall::Types::Pointer`) as with `say`.
>>
>> and:
>>
>> * `<...>` enclosing some OTHER number (NOT the pointer's value,
>>    ie not the address the `Pointer` represents) in DECIMAL literal form.
>>
>> I think this OTHER number is a number associated with the `ObjAt` of
>> the `Pointer`.
>>
>> `ObjAt` is a high level Raku Object ID that's unique to the associated 
>> object.
>>
>> See https://docs.raku.org/type/ObjAt
>>
>> The key thing is that the integer number included in the `.Str` of a 
>> `Pointer`
>> is NOT the address that that `Pointer` points to. It's something 
>> completely
>> unrelated. Unless you know you need to pay attention to its `ObjAt` you
>> are best advised to ignore it.
>>
>> ----
>>
>> To return to the outputs of the `say`/`.gist` and `print`/`put`/.Str` 
>> forms
>> and add the `.raku` at the start:
>>
>> ```
>> ...Pointer.new(42)
>> ...Pointer<0x2a>
>> ...Pointer<5895604297984>
>> ```
>> You thought the three numbers should be the same integer.
>>
>> That's part of the problem. It's a surmise that leads to surprise.
>>
>> ----
>>
>> Your original exploration was in the REPL.
>>
>> By default this REPL line and display uses `.gist`/`say`
>> ```
>> [3] >  my Pointer $Ptr2Ptr  = NativeCall::Types::Pointer[BYTES].new($x);
>> NativeCall::Types::Pointer<0xfe45ddcc>
>> ```
>> (You can change from the default but let's move on.)
>>
>> If a REPL line explicitly writes to STDOUT, then the REPL uses
>> that instead. So this line does NOT use `.gist`/`say`:
>>
>> ```
>> [4] > print "x = <" ~ $x ~ "> <0x" ~ $x.base(16) ~ ">   Ptr2Ptr <" ~
>> $Ptr2Ptr ~ ">\n";
>> x = <4265991628> <0xFE45DDCC>   Ptr2Ptr
>> <NativeCall::Types::Pointer<4852306736864>>
>> ```
>> You wrote `print`, and, as explained at the start, if you do that, the
>> REPL accepts its output and displays that as is, no `.gist` involved.
>>
>> In the meantime, the `$Ptr2Ptr` is concatenated with `...<" ` and `">..."
>> either side of it via two `~`s. The `~` op calls `.Str` on its operands.
>>
>> As explained above the `.Str` of a `Pointer` is not its `.gist` and 
>> instead
>> returns a string that includes an `ObjAt` integer inside the `<...>` and
>> that integer is not the address the `Pointer` points to.
>>
>> ----
>>
>> So, factors that are confusing.
>>
>> Please sleep on what you've learned, and perhaps rethink it through
>> the next day before deciding whether you now find it makes sense or
>> if it remains confusing. Then I'll follow up if you still find it 
>> confusing.
>>
>> Hth!
>>
>> -- 
>> raiph
> 
> 
> Yes it does.  Thank you!
> 
> Oh, I figured out the "*ppXXXXX" double pointer.
> It is "Point[Pointer]", for when one pointer is
> not enough!
> 
> 

"Pointer[Pointer]".  Stinking typos!
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~