Comments on: All hail the “const” parameters!

By: Jon Lennart Aasenden

Jon Lennart Aasenden — Fri, 20 Aug 2010 17:12:56 +0000

The “Var” clause is also pointer based right?

By: Georges Varouchas

Georges Varouchas — Fri, 30 Jul 2010 07:35:42 +0000

Another case when “CONST” makes a big difference : open arrays.

If you call :
function DoSmth( aArray : array of Integer );
DoSmth(myArray) will actually make a *complete copy of myArray’s content on the stack*.

On the other hand :
function DoSmth( const aArray : array of Integer );
DoSmth(myArray) will only take a pointer to myArray.

And obviously, what is mentioned in this post also apply to “var” arguments – together with the advantages and dangers of having parameters passed as reference.

By: Andreas Hausladen

Andreas Hausladen — Thu, 29 Jul 2010 10:26:03 +0000

@Tommi Prami: The option can be set in the project options. But you can enable and disable it in every unit if you want.

By: Tommi Prami

Tommi Prami — Thu, 29 Jul 2010 06:22:20 +0000

@Andreas Hausladen That is so good to know, I am just learlning the Delphi-Unicode world. Not sure about the timeframe when I really need to make the jump, but I've been looking it past few days, and porting some old code for D2009+ and I surely did not know about that option. Is there option in projeect level, or do I need to use .Inc file for that?

By: Andreas Hausladen

Andreas Hausladen — Thu, 29 Jul 2010 05:29:58 +0000

Unfortunately if you have the “{$STRINGCHECKS ON}” (what is the default value) in Delphi 2009/2010. The “const” becomes irrelevant, because the compiler will always emit the implicit try/finally and the code that manages the RefCount. That’s why I disable this stupid compiler option in all of my projects. StringChecks are for not correctly migrated C++Builder projects. Delphi projects experience a bad hit in string-performance.

By: Gad D Lord

Gad D Lord — Wed, 28 Jul 2010 20:23:53 +0000

I have been “const”-ing for about 10 years. Now I have a good “Look – I told you” article to refer to. Thank you for your observations.

By: A. Bouchez

A. Bouchez — Wed, 28 Jul 2010 18:55:23 +0000

const string parameters is always a good idea.

But perhaps it worth saying a word about integer and floating-point parameters: there is no difference in code generation for integer and floating-point values. There is only a difference in usage inside the function/procedure/method: if defined as const, you can’t assign another value to them.

By: François

François — Wed, 28 Jul 2010 17:26:55 +0000

I so fully agree that I wish the default for passing parameters had been const instead of passing them by value.
Then if you’d really need to modify the parameter inside the function you could opt out and specifically choose by ref or by value…

By: Eric

Eric — Wed, 28 Jul 2010 15:48:00 +0000

@Jeroen Pluimers
Fixed, thumbnailing kicked in.
edit… hmm no good, I’ll reenable the thumbnailing, you can click on the mage to get a zoomed unblurred view

By: Eric

Eric — Wed, 28 Jul 2010 15:17:58 +0000

@Rob McDonell
In practice it’ll depend on how you modify the string, and how many times you’ll access the original string during or after its modification.
Thing is, the copy on write mechanism ensures that in the worst case the const version will only be marginally slower, while best case can be faster.
If your function is a very high frequency critical one, won’t evolve much, and you’ve already optimized all that can be, then you could worry about trying to test if removing the ‘const’ brings a plus, though usually there may be better strategies (usually revolving around how and why you modify the passed string).

In all other cases, my advice would be to stick to the safety of ‘const’. There are benefits in terms of debugging, resilience of performance to implementation changes, and maintainability, as it’s simpler to check that all strings are passed as ‘const’ in a library rather than check case by case if it’s worth it not using ‘const’ in some cases