Object and reference to an object

[Martin_fr]

I promised the compiler, I would not touch the value, and therefore the complier skipped ref counting.

This is BS, You do not promise anything to the compiler you instruct the compiler how to handle the data,

You already found the documentation, in fact you quoted the docs

Remark: 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.

Take for example

Code: [Select]

// code assumes {$H+} or string = ansistring;
const
  MyText : String = 'Hello ';
var
  Txt : string;
begin
  Txt := MyText;
  Txt := Txt+'Wooooooooow';
end; 

would you expect the above code to change the data of MyText constant?

No, but

Code: [Select]

  Txt := Txt+'Wooooooooow';
Is making a copy.
Strings are documented to do copy-on-write, if the ref count is bigger than 1

Code: [Select]

  Txt := MyText;
Increased the ref count of the string.


Lets take

Code: [Select]

program Project1;
var s,t: string;
begin
  s := 'foo-bar';
  t := s;
  pchar(@s[4])^ := '+';
  writeln(s);
  writeln(s);
end.
and it does change both.

[taazz]

This is BS, You do not promise anything to the compiler you instruct the compiler how to handle the data,

You already found the documentation, in fact you quoted the docs

Remark: 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.

Of course I found he documentation I like to be aware of any pitfalls I might encounter didn't quoted though. Lets just say that I strongly disagree with that sentence as well the proper statement should be..
 
It is the programmer who tells the compiler that the contents of the const parameter should not be changed.

That means that the compiler is responsible for enforcing that instruction if it does not then there is no point in having it.

Take for example

Code: [Select]

// code assumes {$H+} or string = ansistring;
const
  MyText : String = 'Hello ';
var
  Txt : string;
begin
  Txt := MyText;
  Txt := Txt+'Wooooooooow';
end; 

would you expect the above code to change the data of MyText constant?

No, but

Code: [Select]

  Txt := Txt+'Wooooooooow';
Is making a copy.
Strings are documented to do copy-on-write, if the ref count is bigger than 1

Code: [Select]

  Txt := MyText;
Increased the ref count of the string.

Exactly my point the behavior is counter intuitive for a const parameter and its not the same on all the types making a small by bothersome exception, I would expect that behavior on a var parameter though.

Lets take

Code: [Select]

program Project1;
var s,t: string;
begin
  s := 'foo-bar';
  t := s;
  pchar(@s[4])^ := '+';
  writeln(s);
  writeln(s);
end.
and it does change both.

On that piece of code you intentionally bypassed the fcl string handlers and with that you claim the responsibility that you know what you are doing. It is the same concept with type casting a TObject variable to a TComponent or some other class higher or the hierarchy. Isn't it?

In short I am aware of why that happens I'm just against the current behavior for the above reasons. Is this going to change? I doubt it the dice have fallen and there are code lines out there that depend on this behavior so if I was in charge of that decision I would be against it at this point in time, doesn't make it right though.

[Martin_fr]

Well I cant argue what your likings are.
You are of course free not to like the current language design (the way it is documented and implemented too).

Anyway that is way of the initial point. You made a statement about what one should know about pointers. And I opened the door to a whole world of pointers. I doubt that half the people who clicked the IDE icon, know half all of this.

Sure I brought in automated types. But an object can includes strings. And obj_var.Free will free (deref) those types too. So all this is somewhat still related to the initial question.

Now I thing enough was exchanged on this topic. You can either take my point that contrary to your statement the initial question was not a dummy question at all, or you can ignore my point. Your choice.

As for the welcome of actual dummy questions on this forum: Well we may also have different opinions here. I believe they are welcome.


and by the way
"var" param are not const. they do not have this contract, and they behave like proper refcounted.

Though they probably do not increase the ref either. Because instead of creating a copy of the string-data-pointer, they create a pointer to that pointer.
- "const" param := value // but skip ref counting
- "var" param := @value
- "constref"  param := @value

[taazz]

Errm, I simply voiced my view on the subject of const parameters and how wrong it is form a design point of view, don't confuse me with hinst.

[Martin_fr]

@taazz: My apologies. I did indeed got confused on whom I was talking too.