Recent

Author Topic: [CLOSED] Absolute  (Read 5085 times)

pcurtis

  • Hero Member
  • *****
  • Posts: 841
[CLOSED] Absolute
« on: December 04, 2021, 09:59:30 am »
Is

Code: Pascal  [Select][+][-]
  1. var
  2.   Grid : TStringGrid absolute Sender;
  3.   Grid....
  4.  

the same as

Code: Pascal  [Select][+][-]
  1. (Sender as TStringGrid)....
  2.  
« Last Edit: December 04, 2021, 11:01:29 am by pcurtis »
Windows 10
Laz 2.0.12
FPC 3.2.0

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7684
  • Debugger - SynEdit - and more
    • wiki
Re: Absolute
« Reply #1 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][+][-]
  1. 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][+][-]
  1. var a: longint;
  2. 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.





pcurtis

  • Hero Member
  • *****
  • Posts: 841
Re: Absolute
« Reply #2 on: December 04, 2021, 11:00:34 am »
Thanks.

So the answer is more or less the same.
Windows 10
Laz 2.0.12
FPC 3.2.0

howardpc

  • Hero Member
  • *****
  • Posts: 3856
Re: Absolute
« Reply #3 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][+][-]
  1. var
  2.   grid: TStringGrid absolute Sender;
  3. begin
  4.  
  5.   if Sender.InheritsFrom(TStringGrid) then
  6.     begin
  7.        grid...
  8.    end;
  9.  
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.
« Last Edit: December 04, 2021, 11:03:38 am by howardpc »

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: [CLOSED] Absolute
« Reply #4 on: December 04, 2021, 03:39:51 pm »
Absolute performs zero compiler checks:
Code: Pascal  [Select][+][-]
  1. var
  2.   a: Byte;
  3.   b: TStringList absolute a;
  4. begin
  5.   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][+][-]
  1. var
  2.   a: Byte;
  3. begin
  4.   a := Byte(TStringList.Create)
  5. 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

pcurtis

  • Hero Member
  • *****
  • Posts: 841
Re: [CLOSED] Absolute
« Reply #5 on: December 04, 2021, 03:59:45 pm »
So the answer becomes similar, but don't use.
Windows 10
Laz 2.0.12
FPC 3.2.0

440bx

  • Hero Member
  • *****
  • Posts: 2623
Re: [CLOSED] Absolute
« Reply #6 on: December 04, 2021, 04:03: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. 
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: [CLOSED] Absolute
« Reply #7 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

engkin

  • Hero Member
  • *****
  • Posts: 3057
Re: [CLOSED] Absolute
« Reply #8 on: December 04, 2021, 08:31:21 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?

engkin

  • Hero Member
  • *****
  • Posts: 3057
Re: [CLOSED] Absolute
« Reply #9 on: December 04, 2021, 08:34:31 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?

Warfley

  • Hero Member
  • *****
  • Posts: 654
Re: [CLOSED] Absolute
« Reply #10 on: December 04, 2021, 11:41:20 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
« Last Edit: December 04, 2021, 11:45:45 pm by Warfley »

440bx

  • Hero Member
  • *****
  • Posts: 2623
Re: [CLOSED] Absolute
« Reply #11 on: December 05, 2021, 12:32:17 am »
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. ;)
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

 

TinyPortal © 2005-2018