to const or not to const

[taazz]

From the doc:

Note that specifying const is a contract between the programmer and the compiler. It is the programmer who tells the compiler that the contents of the const parameter will not be changed when the routine is executed, it is not the compiler who tells the programmer that the parameter will not be changed.

Why would I need to specify a const then? just add a comment on top of the procedure please do not change the param1 value and you are done.
If what the documentation says is true which its not and can be simple proved with the following example.

Code: [Select]

procedure Test(Const a:string);
begin
  a:='This should not be allowed';
end;can this be done? if not then why if the compiler is not enforcing the const then who is?

[Martin_fr]

That is documented do:

Code: [Select]

and also to perform certain checks on the code inside the routine: namely, it can forbid assignments to the parameter.
That is not in conflict with the rest of the doc.

Here is another bit from that doc:

Code: [Select]

Specifying a parameter as Constant is giving the compiler a hint that the contents of the parameter will not be changed by the called routine
There is  a difference  between "assignments to the parameter" (changing it directly)
and
"contents of the parameter will not be changed by the called routine" which is any change, including change by pointer hacks, change by calling other functions that change it, .....

[taazz]

yeah I've read the docs and I do disagree on all counts. defining a parameter as const the compiler protects the parameter from assinging to it an other value not from the hacks that I might come up with to trick the compiler and change that value. But then again we are out of context for this thread. I'm not going to start a rewrite the documentation thread I'm stating the blindly obvious here.

[stocki]

const or no const on integer, tobject, etc has no effect on the produced code. Exception: string. There will be heavy ref count pre and postfix stuff without const (seen in Delphi xe6, FPC debugger is junk).

[taazz]

const or no const on integer, tobject, etc has no effect on the produced code. Exception: string.

open arrays,dynamic arrays and managed types in general.

[Dibo]

Didn't read all discussion but isn't const (like var) faster if you pass big string? Let say that you need to pass some big string (HTML) into parser function/method and you call this function many times in loop. Without const a copy of string will be passed on each loop (which could be expensive), with const a reference will be passed (direct pointer in memory) or am I wrong?

[taazz]

there are 3 possibilities 1) const 2) var 3) by val (VB terminology) in const and var a reference is passed on by val it should be a copy bu since there is the copy on write mechanism for string a reference could possible do the same thing I did not check it so I"m not 100% sure about the 3rd option it is one that I never use my self.

[BeniBela]

The most confusing/annoying part of this is, when the compiler starts aliasing variables that do not look like they are the same variable

Code: [Select]

function trimLeft(const s: string): string;
var skip: Integer;
  i: Integer;
begin
  skip := 1;
  while s[skip] = ' ' do inc(skip);
  SetLength(result, length(s) - skip);
  if result = '' then exit;
  for i := 1 to length(result) do
    result[i] := s[i+skip-1];
end;

A perfectly reasonable way to write a trim function.

Search the non space part in the old variable (s) and copy it to a new variable (result)

And then it blows up, because result and s might be the same variable...

[Leledumbo]

Didn't read all discussion but isn't const (like var) faster if you pass big string? Let say that you need to pass some big string (HTML) into parser function/method and you call this function many times in loop. Without const a copy of string will be passed on each loop (which could be expensive), with const a reference will be passed (direct pointer in memory) or am I wrong?

Read the first remark: http://www.freepascal.org/docs-html/ref/refsu63.html