Forum > Beginners

[Solved] Is it possible to const an argument passed by reference in FPC?

<< < (4/13) > >>

ASerge:

--- Quote from: 440bx on July 25, 2019, 10:01:56 am ---"var" and "constref", yes, because they are well defined. "const" no, because its meaning is, in addition to being anyone's guess, as you pointed out it might change in the future.

--- End quote ---
Still, pascal is not an assembler. The level of abstraction allows you not to think about implementation. But the const modifier avoids errors when the input parameter changes inside the function.
I would have changed the approach. The default is to consider all the parameters are const by default. I.e. it is impossible to assign them something. If want to change, declare a local variable and assign to it. In this case, the const modifier could be omitted. And there are languages where the input parameter cannot be changed if it is not explicitly declared changeable (var in Pascal).

440bx:

--- Quote from: ASerge on July 25, 2019, 10:55:40 am ---But the const modifier avoids errors when the input parameter changes inside the function.

--- End quote ---
If the const modifier had a consistent and predictable behavior, I would completely agree with that statement.  Unfortunately, in FPC, the behavior of the "const" modifier isn't really consistent and predictable.  For that reason, I don't use it.  In addition to that, considering that its semantics may change in a future implementation of FPC, using it invites introducing future incompatibilities.

All that said, if the const modifier always meant "constant" and nothing else then, I could agree with your statement without reservations.


--- Quote from: ASerge on July 25, 2019, 10:55:40 am ---The default is to consider all the parameters are const by default. I.e. it is impossible to assign them something. If want to change, declare a local variable and assign to it. In this case, the const modifier could be omitted. And there are languages where the input parameter cannot be changed if it is not explicitly declared changeable (var in Pascal).

--- End quote ---
I think that is quite sensible and would make the code more robust.

marcov:

--- Quote from: 440bx on July 25, 2019, 12:54:04 pm ---
--- Quote from: ASerge on July 25, 2019, 10:55:40 am ---But the const modifier avoids errors when the input parameter changes inside the function.

--- End quote ---
If the const modifier had a consistent and predictable behavior, I would completely agree with that statement.  Unfortunately, in FPC, the behavior of the "const" modifier isn't really consistent and predictable.  For that reason, I don't use it.  In addition to that, considering that its semantics may change in a future implementation of FPC, using it invites introducing future incompatibilities.

--- End quote ---

Simple. The few places where it (due to external interfaces) must be fixated, use constref. For the rest, use const.
 

440bx:

--- Quote from: marcov on July 25, 2019, 01:58:08 pm ---Simple. The few places where it (due to external interfaces) must be fixated, use constref. For the rest, use const.

--- End quote ---
If any of the FPC manuals was clear and unequivocal about the behavior of "const" under which conditions then, I would use it but, the FPC manuals are rather wishy-washy as to what "const" may or may not do, for that reason, I don't trust it, therefore I don't use it.

Also, after this statement from PascalDragon:

--- Quote from: PascalDragon on July 25, 2019, 09:55:53 am ---Also the behaviour of const might change with each version of FPC as it's not part of the platform ABI, thus it might be that in some newer version it's decided to pass a parameter type in a more optimal way.

--- End quote ---
I am even less inclined to use it.

I'm fine with constref or passing by value.  Not quite the same but, safe and predictable.

Zoran:

--- Quote from: 440bx on July 25, 2019, 02:54:07 pm ---
--- Quote from: marcov on July 25, 2019, 01:58:08 pm ---Simple. The few places where it (due to external interfaces) must be fixated, use constref. For the rest, use const.

--- End quote ---
If any of the FPC manuals was clear and unequivocal about the behavior of "const" under which conditions then, I would use it but, the FPC manuals are rather wishy-washy as to what "const" may or may not do, for that reason, I don't trust it, therefore I don't use it.

Also, after this statement from PascalDragon:

--- Quote from: PascalDragon on July 25, 2019, 09:55:53 am ---Also the behaviour of const might change with each version of FPC as it's not part of the platform ABI, thus it might be that in some newer version it's decided to pass a parameter type in a more optimal way.

--- End quote ---
I am even less inclined to use it.

--- End quote ---
No, what PascalDragon said is not that.
The meaning of const will not change in future versions.
But you should understand well that the meaning of const has nothing to do about whether it is passed by reference or by value.

Unless for some reason you need to know whether it will be passed by value or by reference (and you would very rarely need to know it, why would you?), use const and the compiler will make the decision how it will be passed and try to decide what is more optimal.
Only that decision is what may change, but it actually has nothing to do with const's meaning in fpc.

When you want to force the compiler to pass by refernce, use var.

The combination of these two unrelated things (parameter which are not allowed to be changed in procedure body, and passing by reference) is very rarely needed.
Why would you need to force passing by reference, why would you care how will it be passed, if you do not intend to change the parameter?

When for some reason (external interfaces as Marco says, and hardly anything else) you need these two unrelated things, there you can use constref.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version