Lazarus

Free Pascal => General => Topic started by: pcurtis on December 04, 2021, 09:59:30 am

Title: [CLOSED] Absolute
Post by: pcurtis on December 04, 2021, 09:59:30 am

var
  Grid : TStringGrid absolute Sender; 
  Grid....
 

the same as

Code: Pascal [Select][+]

(Sender as TStringGrid)....
 

Title: Re: Absolute
Post by: Martin_fr on December 04, 2021, 10:40:14 am

All the below are assumptions

"as" afaik includes type safety checking, and can throw an exception if the instance in Sender is not a related class...

So if anything then

Code: Pascal [Select][+]

TStringGrid(Sender)

But I am not 100% sure, if there are any minor details that differ...

One thing: Casting only works for some types. You can't do "TMyRecord(somevar)". But you should be able to use absolute in that case.

And (I guess) depending on endian-ness

Code: Pascal [Select][+]

var a: longint;
b: byte absolute a;

This may differ to "Byte(a)". I would expect "Byte(a)" to return the low-byte. But absolute to depend on memory order.
On little endian, the lowest-order byte is first => at the same address as the longint
On big endian, the lowest-order byte is last => at "PByte(@a)+3"

In your case, both types have the same size. So that is not an issue.

Title: Re: Absolute
Post by: pcurtis on December 04, 2021, 11:00:34 am

Thanks.

So the answer is more or less the same.

Title: Re: Absolute
Post by: howardpc on December 04, 2021, 11:01:27 am

No, similar, but not the same.
When casting Sender to a descendant class, it is wise to check that the cast is valid.
"as" checks and raises an exception for an invalid cast, as Martin_fr writes.
An alternative, better, in most circumstances unless you want the user to see the potential exception, is to guard the implicit absolute cast with

Code: Pascal [Select][+]

var
  grid: TStringGrid absolute Sender;
begin 
 
  if Sender.InheritsFrom(TStringGrid) then
    begin
       grid...
   end;
 

This simply fails to run the grid's block of code if it is not valid to do so, without raising an exception.

Most exceptions seen by users indicate a shortcoming in the programmer's approach.

Title: Re: [CLOSED] Absolute
Post by: Warfley on December 04, 2021, 03:39:51 pm

Absolute performs zero compiler checks:

Code: Pascal [Select][+]

var
  a: Byte;
  b: TStringList absolute a;
begin
  b := TStringlist.Create; 

This is broken code, it compiles without a warning or error but completely smashes your stack.
But if you try the following:

Code: Pascal [Select][+]

var
  a: Byte;
begin
  a := Byte(TStringList.Create)
end.

The compiler will throw an error that what you are trying to do is wrong.

IMHO there is absolutely no case where absolute is a good idea. If Access to the same memory is required, variant records and/or (pointer) casting is always preferential, as it archives the same effect, while 1. being more verbose about what is actually happening here and 2. performs error checking

Title: Re: [CLOSED] Absolute
Post by: pcurtis on December 04, 2021, 03:59:45 pm

So the answer becomes similar, but don't use.

Title: Re: [CLOSED] Absolute
Post by: 440bx on December 04, 2021, 04:03:51 pm

Quote from: Warfley on December 04, 2021, 03:39:51 pm

IMHO there is absolutely no case where absolute is a good idea. If Access to the same memory is required, variant records and/or (pointer) casting is always preferential, as it archives the same effect, while 1. being more verbose about what is actually happening here and 2. performs error checking

It isn't my intention to be argumentative but, there are occasions where "absolute" is a better choice than typecasting. Some of the examples that come to mind include:

1. Some Window message apply a structure to wParam, lParam or both. It works as documentation to absolute the structure on top of the parameter and, if either parameter is used often in the processing of the message, there is a lot less clutter than having to typecast every use.

2. Similar to (1) above. When creating a thread, it is common to pass a parameter to the thread, usually as an untyped pointer. The thread function receives it as an untyped pointer and, IMO, it is cleaner and much simpler to "absolute" the correct pointer type of top of the thread parameter.

3. Similar to (2) above. When using external sort routines, those routines specify an untyped pointer. The implementation of the compare function receives that untyped pointer and the simplest and, IMO, most informational is to "absolute" the correct pointer type on top of compare function parameters.

Those are three instance I can think of off the top my head as I type this and, and I know there are more than that.

All that said, I completely agree that someone who doesn't understand what absolute does would be very wise to stay away from it.

Title: Re: [CLOSED] Absolute
Post by: Warfley on December 04, 2021, 06:00:44 pm

About 2 and 3, what I like to do is to simply define them with the "correct" pointer type and typecast the function pointer when providing the callback parameter

Title: Re: [CLOSED] Absolute
Post by: engkin on December 04, 2021, 08:31:21 pm

Quote from: Warfley on December 04, 2021, 06:00:44 pm

About 2 and 3, what I like to do is to simply define them with the "correct" pointer type and typecast the function pointer when providing the callback parameter

What makes this typecast better than using absolute?

Title: Re: [CLOSED] Absolute
Post by: engkin on December 04, 2021, 08:34:31 pm

Quote from: 440bx on December 04, 2021, 04:03:51 pm

All that said, I completely agree that someone who doesn't understand what absolute does would be very wise to stay away from it.

Wouldn't it be better to learn what absolute does and use it appropriately?

Title: Re: [CLOSED] Absolute
Post by: Warfley on December 04, 2021, 11:41:20 pm

Quote from: engkin on December 04, 2021, 08:31:21 pm

What makes this typecast better than using absolute?

The compiler perfroms error checking on typecasts, see the example from above. or do you mean in this specific circumstance, there it shifts the conversion from the declaration of the function to the use point, making the function itself cleaner and easier to understand

Title: Re: [CLOSED] Absolute
Post by: 440bx on December 05, 2021, 12:32:17 am

Quote from: engkin on December 04, 2021, 08:34:31 pm

Wouldn't it be better to learn what absolute does and use it appropriately?

Yes, it would but, until they do that, they should probably stay away from it. ;)