to const or not to const

[hinst]

I sometimes wish that FreePascal didn't have const modifier for function arguments at all. Because I often find myself thinking whether I should use it in every particular case or not

Code: [Select]

procedure WriteStuff(s: string);
//or
procedure WriteStuff(const s: string);

Code: [Select]

procedure CalcNumber(i: Integer);
//or
procedure CalcNumber(const i: Integer);
I am kind of aware of effects caused by const modifier. For example, when string argument is declared const, compiler does not enable reference counting for it (in this particular procedure)
However, it does not make things easier for me because I still have to think "do I need reference counting in this case or not". With reference counting enabled it feels somehow safer while with reference counting disabled the code should generally work faster

Do you put const everywhere or avoid it at all? or spend time thinking in each case?

What about class instance variables?

Code: [Select]

procedure PrintObject(o: TMyObject);
//or
procedure PrintObject(const o: TMyObject);
In 99% of procedures I do not assign values to arguments in procedure body. So should they be const? Not sure if const makes code more readable or otherwise

[marcov]

Probably they should be const yes. But usually I only care for the distinction in reusable, somewhat performance sensitive code. Which is only like 1-2%. And even that is inflated because somewhat used to thinking about it due to work on the RTL.

[garlar27]

I put const everywhere with few exceptions.

[taazz]

I put const everywhere with few exceptions.

+1
Everything is const unless there is a reason to make var. I never use by value parameters aka no designation at all never find any use for it really other than do not declare a new variable inside the procedure/method.

[Leledumbo]

Yep, const most of the time. Guarantee of a parameter being accidentally modified. If you need to modify, make a local copy first.

[eny]

I put const everywhere with few exceptions.

+1

+1

A side effect concerning reference counting is that there is a bug in the handling of interfaces. Passing an interface as a const parameter will make your program a memory-leakage waterfall.
This is a bug in FPC, undocumented and you are not warned by the compiler.
(You have been warned now...)

[Blaazen]

Code: [Select]

procedure CalcNumber(i: Integer);What's wrong with this? It's called by value, if you don't need the value anymore you can modify it (and you don't need new local var) and when procedure's over changes are forgotten.

[eny]

Code: [Select]

procedure CalcNumber(i: Integer);What's wrong with this? It's called by value, if you don't need the value anymore you can modify it (and you don't need new local var) and when procedure's over changes are forgotten.

It helps you in documenting the program and making it easier to understand by others.
Also the compiler helps you in blocking assignments or changing the variable.
So that in case you expect to return a value, you are hinted that that is not possible.

[Blaazen]

AFAIR in past Lazarus autocomplete had created setters with const, then was a huge discussion on the mailing list and it resulted to change to non-const setters.

[taazz]

AFAIR in past Lazarus autocomplete had created setters with const, then was a huge discussion on the mailing list and it resulted to change to non-const setters.

So who is responsible for me doing all the const adding manually? and even more important why?

[Blaazen]

So who is responsible for me doing all the const adding manually? and even more important why?

There were two big discussions in past. One was about "dangerous" with..do construction, AFAIR initiated by Ido Kanner.
The second, about const was initiated AFAIR by programmer with russian name. I just don't remember if it was Lazarus or FPC ML, and I can't find it in archives.

[marcov]

Code: [Select]

procedure CalcNumber(i: Integer);What's wrong with this? It's called by value, if you don't need the value anymore you can modify it (and you don't need new local var) and when procedure's over changes are forgotten.

It helps you in documenting the program and making it easier to understand by others.

It adds an unnecessary indirection and thus slows down on many ABIs :-)

[Blaazen]

So who is responsible for me doing all the const adding manually? and even more important why?

You can try to put feature request to add one checkbox to Lazarus Options. Also, there is new define EnableCodeCompleteTemplates (under development !) where you can manually add "const" to ..lazarus/components/codetools/codecompletiontemplates.xml

[howardpc]

So who is responsible for me doing all the const adding manually? and even more important why?

There were two big discussions in past. One was about "dangerous" with..do construction, AFAIR initiated by Ido Kanner.
The second, about const was initiated AFAIR by programmer with russian name. I just don't remember if it was Lazarus or FPC ML, and I can't find it in archives.

I think there may have been several discussions of const. One that ran for several days was started in the fpc-devel ML by Chad Berchek on 4 July 2011, "const optimization is a serious bug".

[Blaazen]

Yes, this looks familiar  : http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg22104.html