What does [ref] attribute actually dows

[Tommi Prami 138]

Hello,

 

Tried to find the documentation of [ref] attribute, famously used in FreeAndNil -implementation lately, but could not find it from Embacdero help.
(FreeAndNil is defined as: procedure FreeAndNil(const [ref] Obj: TObject);)

So could someone point me to the documentation of the attribute ands/or explain what it actually does?

 

-Tee-

[Stefan Glienke 2069]

It is briefly explained under Constant Parameters - it enforces the parameter to be passed as a reference.

[havrlisan 32]

Dalija Prašnikar has a great article on what it's purpose is in FreeAndNil: https://dalijap.blogspot.com/2020/06/magic-behind-freeandnil.html

[Tommi Prami 138]

I have been in impression that const actually would do something like that already. So parameter would be passed as reference.  Will juust not allow changin it....

Is there some clear benefit of using [ref],m unless in need of doing something like in  the FreeAndNil iomplementation.

[Hans♫ 78]

3 minutes ago, Tommi Prami said:

Is there some clear benefit of using [ref],m unless in need of doing something like in  the FreeAndNil iomplementation.

I think the answer is in this text from the FreeAndNil article linked above:

 

... [ref], which forces the compiler to pass a const parameter as a reference. Without it, the compiler can optimize passing of const parameter depending on the size of the parameter. 

[Tommi Prami 138]

23 minutes ago, Hans♫ said:

I think the answer is in this text from the FreeAndNil article linked above:

 

... [ref], which forces the compiler to pass a const parameter as a reference. Without it, the compiler can optimize passing of const parameter depending on the size of the parameter. 

Tried that with record as parameter, did not see any speedup, const and const [ref] had same performance. 

Winning clearly if it was passed as by value eith const ore var.

I was jsut thinkin that could there be places and code (in my code ba se for example) thjat could benefit from [ref]?

-Tee-

Edited 10 hours ago by Tommi Prami

[havrlisan 32]

16 minutes ago, Tommi Prami said:

I was jsut thinkin that could there be places and code (in my code ba se for example) thjat could benefit from [ref]?

Only if you need to access the actual reference.

[Hans♫ 78]

50 minutes ago, Tommi Prami said:

Tried that with record as parameter, did not see any speedup, const and const [ref] had same performance. 

Thats because there is no difference. As the text says, with "const" only, the compiler decides the most efficient way. For a record the most efficient way is to pass its reference, so adding [ref] makes no difference.

[Rollo62 560]

3 minutes ago, Hans♫ said:

For a record the most efficient way is to pass its reference, so adding [ref] makes no difference.

Is that always guaranteed?
I would think that the compiler may decide to copy by value for small records.

[Hans♫ 78]

19 minutes ago, Rollo62 said:

Is that always guaranteed?

Ha, ha, I am sure you know what I mean 😉 I'm no expert in the compilers memory management and optimization. I was trying to explain why it made no difference to add [ref]. 

I guess that if you create a "packed" record that is smaller than a pointer then it will be passed by value.

Edited 8 hours ago by Hans♫

[HeartWare 5]

CONST [ref] is on the surface the same as VAR but it allows a CLASS variable of a descendant to be passed. So where a VAR TObject only allows variables declared as TObject, a CONST [ref] TObject parameter passes a reference (like VAR does) to the instance pointer, but allows all descendants of TObject to be passed in. This eliminates the issue with a typeless VAR to FreeAndNIL also accepting non-classes.

[Cristian Peța 111]

3 hours ago, Tommi Prami said:

I have been in impression that const actually would do something like that already

With const, if the variable is small enough to pass into a registry, it will not be passed always as reference. You need to use [ref] to be sure it is passed as reference. This is the reason to use [ref] for FreeAndNil.