to const or not to const

[hinst]

nothing is ever easy

[taazz]

well a lot of good information is been put in the first post a very good case to eliminate that optimization once and for all or at least provide a way to get the original use of const back and add it as a manuall optimization is needed (compiler directive?). In any case I thank you all for the interesting link haven't finished reading through to have an overview yet, so back to my reading and thanks once more.

[eny]

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

Humans read sourcecode not ABI's   

[Martin_fr]

Humans read sourcecode not ABI's   

Which would perfectly explain, why to use "const" for function parameters. After all, this is probably one of the declarations most often misread by humans....

Code: [Select]

program Project1;
type TMyRec = record x1,x2,x3,x4,x5: integer; end;
var a: TMyRec;

procedure Bar;
begin
  a.x2 := 2;
end;

procedure Foo(const b: TMyRec);
begin
  Bar;
  writeln(b.x2);  // prints "2"
end;

begin
  a.x2 := 1;
  Foo(a);
  readln;
end.

Foo is called with a record, that has "x2 = 1".
Yet the above code will print out "2". (Btw, it is not guaranteed to print 2, the behaviour of above code is undefined , it just happens to print 2, in most cases)


Would you (as a human) have read that from the code?

Btw: The compiler behaves exactly as it is documented.


And to make thinks even better, if you declare:

Code: [Select]

type TMyRec = record x2: integer; end;
Then it will in most cases print "1"

[hinst]

Well, what I think every time I want to add const is:

  It will work faster this way, but it's safer without it. I should be careful not to screw this

And by "screw this" I mean "either accidently modify const value in some indirect way or loose all references to it before the routine exits"

...However in my experience so far I never had problems caused by const modified or deleted

[garlar27]

Humans read sourcecode not ABI's   

Which would perfectly explain, why to use "const" for function parameters. After all, this is probably one of the declarations most often misread by humans....

Code: [Select]

program Project1;
type TMyRec = record x1,x2,x3,x4,x5: integer; end;
var a: TMyRec;

procedure Bar;
begin
  a.x2 := 2;
end;

procedure Foo(const b: TMyRec);
begin
  Bar;
  writeln(b.x2);  // prints "2"
end;

begin
  a.x2 := 1;
  Foo(a);
  readln;
end.
...

I don't know from where you took the example code you posted above. But, when I see something like this, my first thought is: the problem is a "POOR DESIGN".

I have seen enough other people's code in my job to believe that some progamers think that PROGRAMING and a JAZZ JAM SESSION are the same thing.

[Martin_fr]

I don't know from where you took the example code you posted above. But, when I see something like this, my first thought is: the problem is a "POOR DESIGN".

It seems you misunderstood something here. The code is exactly what you called it "example code".

It is not meant to be used like this, it simply demonstrates a specific point, without paying any attention to the quality of that code. The quality of the code does not matter since it is not meant to be used. After all, it has a bug deliberately placed in it.

I am not going to play a symphony, if I want to demonstrate that a musical instrument is out of tune.

[garlar27]

I don't know from where you took the example code you posted above. But, when I see something like this, my first thought is: the problem is a "POOR DESIGN".

It seems you misunderstood something here. The code is exactly what you called it "example code".

It is not meant to be used like this, it simply demonstrates a specific point, without paying any attention to the quality of that code. The quality of the code does not matter since it is not meant to be used. After all, it has a bug deliberately placed in it.

I am not going to play a symphony, if I want to demonstrate that a musical instrument is out of tune.

Sorry, my english is getting worst year after year 
I understood what you said from the start, but ...

Once upon a time (few year ago when starting with Lazarus) I had a problem with the use of const parameters. My silly first thought was "FPC" has a bug. Never the less I needed to solve it some how and go ahead.
After many unsucceful tries, I stepped back to have a wider look and see the objective vs. what I was doing.

Then I saw it: I MADE A POOR DESIGN.
I was ashamed because I wrote a method with a const param, which used another method to modify a variable. In some cases the variable to modify and the one used as const parameter WERE THE SAME!!!

For god sakes!!! What the hell I was thinking?! I was thinking? Really?

If compiler would allowed me to do that, the things would have worked from the start (really?).
But I had to rethink the whole process and I came with a better solution:
   o- More reusable.
   o- Easier to understand.
   o- Easier to maintain.

I want to remark something you said:

Btw: The compiler behaves exactly as it is documented.

[Martin_fr]

Ok, now I see what you mean.

Yes in that sense my code is bad design. But I made it intentionally so. I wanted it to be, in order to show the problem.

You may already know the correct usage of "const", and the OP probably does too.
Possible (likely) on this thread there are more people who do.

But in generic, past postings of others show, that many do not. Many expect "const" to mean something else.

[Mike.Cornflake]

You may already know the correct usage of "const", and the OP probably does too.
Possible (likely) on this thread there are more people who do.

I'm embarrassed to admit this, but I'm doing so in case there other confused people out there.  I have *NO* idea what the correct usage of const is.  I've read this topic thoroughly, I've read through the links provided (with a growing sense of trepidation I might add), and I've read all I can find by googling.  And I'm still not clear, but I do know that in my ignorance, I'll be avoiding Const like the plague.  Pascal shouldn't be this hard :-)

[Martin_fr]

"const" for a function parameter, is a promise made by the programmer to the compiler, that the programmer has taken care that the value in the variable will not change.

"const" for a function parameter, in NOT a way to ask the compiler to enforce this, the compiler will not (and can not).

The compiler will show obvious errors, but not such as in my example. In my example I break the promise I made. I change the value of "b", since b is a pointer/reference to "a", and I do change "a".


If a was a string, dyn array, or I would otherwise change memory allocation of the variable pointed to, then it may lead to a crash.

----------------
The problem is, that many people believe "const" for a function parameter, is a directive to the compiler to enforce the variable to not be changed.

And as said, it is not.

---------------
http://www.freepascal.org/docs-html/ref/refsu63.html#x166-17600014.4.4

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.

"called routine" includes all nested calls

[taazz]

ok I run the same code under Delphi 2007 and it produces the same results it prints 2 when TmyRec is declared with more than one integer fields and 1 when the record has a single integer field.

To make things clear this happens because the type's size is small enough to pass the value directly instead of the memory address and in doing so it automatically protects the data from outside interference that might wanted or not its a problem of the design not the compiler.

Although it seems inconsistent it is a known and well documented behavior so there is nothing to fear about this.

The "bug" with the const optimization exhibits it self only with managed types (egstrings) and can be easily solved by adding a var inside the procedure and assign the const parameter to it or at least I think it can be solved this way haven't done any real testing.
Avoiding const would mean that

Code: [Select]

procedure DoSomething(Param1:TMyRec);
begin
end;will copy the contents of which ever variable it is passed to the this procedure before calling it adding an overhead and declaring as var will leave you open to algorithm bugs changing the values in it so const is the steel the logical choice for me.

[Mike.Cornflake]

"const" for a function parameter, is a promise made by the programmer to the compiler, that the programmer has taken care that the value in the variable will not change.

"const" for a function parameter, in NOT a way to ask the compiler to enforce this, the compiler will not (and can not).

I see.  So it's there so we can help the compiler with its optimisations, and not for the compiler to help us (though the compiler will try and catch the obvious misuses)

The problem is, that many people believe "const" for a function parameter, is a directive to the compiler to enforce the variable to not be changed

And this was my original belief too.

Many thanks for the clarification.

[taazz]

"const" for a function parameter, is a promise made by the programmer to the compiler, that the programmer has taken care that the value in the variable will not change.

Please stop saying that, it is as meaningful as me giving my word to a chair that I will not sit on it. It makes no sense to have a contract with the compiler for what ever reason.

I instruct the compiler to keep the contents of the const parameter read only inside the procedure it is declared that is all there is to it. no one said that the compiler will enforce a read only policy to the memory the parameter points to so while in the procedure nothing can change it.

If this is not clear to someone then he needs to read the basics again.

The "bug" how ever is very real and it comes down to managed types where the const parameter do not add to the reference counting of that variable making it extremely easy for that variable to be freed while inside the procedure and in the world of  asynchronous and multi thread programming of today you never know when this will happen just to gain a couple of cycles from the try..finally block that is auto introduced for managed types.

In short that is the problem with the const every one is so concerned about.

[minesadorada]

Interesting discussion.

I have always assumed "if you can declare a parameter as a Const, then do" - thinking that it would save memory and execution time etc.   Most times, it's pretty clear whether you are going to change the value of the parameter or not in the routine.

I must admit; most times I forget, then sometimes refactor them in