pointers in relation to Addresses of variables

[rrpl]

From the PB help file under pointers in relation to Addresses of variables it says;

"To find the address of a variable in your code, you use the at symbol (@). A common reason for using this is when you want to pass a structured type variable to a procedure. You must pass a pointer to this variable as you cannot pass structured variables directly.

Example"

Code: Select all

Structure astruct
    a.w
    b.l
    c.w
  EndStructure
  
  Procedure SetB(*myptr.astruct)
    *myptr\b = 69
  EndProcedure
  
  Define.astruct myvar
  
  SetB(myvar) ;Example has: SetB(@myvar)
  
  Debug myvar\b ; same result as SetB(@myvar)

So why does it still work OK when I just use the structured variable.
Is this a new automatic feature of PB that you don't need the @?
Or does it only work in some cases, or is it something else all together that I'm not comprehending (most likely! ).

[Fig]

Please give us your code "when I just use the structured variable."

[idle]

It's been like that for awhile if I recall but I don't know if it's intended or not
so if it's a pointer parameter pass the @ to be on the safe side

[luis]

So why does it still work OK when I just use the structured variable.

The PB compiler always passes the address of a structure without raising an error even if the @ is missing.

When you pass elementary data types like an integer or a float, they are copied by default, so you NEED to use @ to pass their address.
When you pass a string, again the string is copied by default so you NEED to use @ to pass its base address.
PB simply does not support passing a structure by value (a copy of it) like some other languages, so your only option is to use @.
Since this is your only option maybe Fred decided to go for it by default, or it was just a consequence of how the compiler was written.
In any case, that's how it is.

Or does it only work in some cases, or is it something else all together that I'm not comprehending (most likely! )

No, yours is a good question and I found the ability do to so not very consistent with the other cases.


Anyway: I always use @ when passing a structure, even if not required, for clarity an consistency.
Also doing hopefully the most logical thing even when you have the option of using a less strict syntax which is currently accepted sometimes pays off.

[BorisTheOld]

So why does it still work OK when I just use the structured variable.

The PB compiler always passes the address of a structure without raising an error even if the @ is missing.

I think it would save a lot of confusion if the documentation did a better job of explaining that passing Structures is just like passing Arrays, Maps, and Lists. All are complex structures that are passed By Reference, therefore the "@" isn't required for the call. But unlike Arrays, Maps, and Lists, the type name "Structure" isn't needed in the procedure parm.

[luis]

passing Structures is just like passing Arrays, Maps, and Lists

But unlike Arrays, Maps, and Lists, the type name "Structure" isn't needed in the procedure parm.

Not exactly.

When you pass the address of the structure with "@", or as it is currently possible with nothing at all, you end up with a pointer to the structure, like when you pass the address of simpler types.
You have to dereference that address to access the original variable.

When you pass an array, list or map using the keywords Array, List, Map you end up auto-magically with a sort of alias of the original var passed, and you can use it just as if it was a locally defined var.

So two different approaches are used, and the @ has its place for structures IMO.

[BorisTheOld]

Not exactly

I thought you'd point that out to me.

I was trying to keep things at a conceptual level, rather than get into low-level implementations.

There's really no reason why Structures should be treated differently from Array, Map, and List, since they are all complex structures accessed By Reference. Especially as PB already does half the job by allowing calls to be made without the "@" character.

In many respects, PB is a strange hybrid of both high-level and low-level languages, which can be a little disconcerting to new users or those with little knowledge of what actually goes on deep inside the code. It shouldn't be necessary for PB programmers to dereference pointers for features that other compilers handle automatically. It's been more than 50 years since call By Reference became a standard feature of programming languages.

Be that as it may, PB is still my language of choice. Anything I don't like about PB syntax I wrap in a macro. It's amazing how a PB program can be made to not look like a PB program.

[Kuron]

It's amazing how a PB program can be made to not look like a PB program.

[rrpl]

Thanks for the answers @idle, @luis and @boristheold.
I'm not very good at understanding pointers, so thanks for the info.
Seems like I should still with the "@" just to be on the safe side