Why is it not possible to inc(tag)

[Kraig]

Hello
I’m curious why it isn’t possible to increment the tag field of a control like this inc(tag) .
It says error: can’t take the address of a constant expression. Why does it do that? Yes I know I can do tag:= tag + 1; but I’m still curious

[lainz]

Hello
I’m curious why it isn’t possible to increment the tag field of a control like this inc(tag) .
It says error: can’t take the address of a constant expression. Why does it do that? Yes I know I can do tag:= tag + 1; but I’m still curious

Hi, because it's a property, so the program can't access the internal data of the object. Usually the real data is shadowed with a getter and a setter...

[jamie]

It's an honoree compiler ? 

Code: Pascal  [Select][+][-]

1.  Inc(PQWord(@Tag)^);    //For 64 bit systems.
2.  

 

A little added fluff!

Code: Pascal  [Select][+][-]

1. Procedure IncTag(ATag:PPtrUint;ACount:PtrUint=1); inline;
2. Begin
3.   Inc(ATag^,ACount);
4. end;
5.  
6. procedure TForm1.Button1Click(Sender: TObject);
7. begin
8.   IncTag(@Tag);
9.   Caption := Tag.Tostring;
10. end;                                  
11.  

You need only to supply the item via address.

You can also use signed count to go backwards so you don't need to have a DEC

[Kraig]

Thanks for the answers and creative workaround 

That’s interesting I guess the mechanism of doing tag:= tag +1 is somehow different than inc(tag); Because inc () is a procedure call maybe..

[kjteng]

IMHO, it is not advisible to pass a property as a parameter for inc or dec funciton because an object property may has its own setter which may perform other operation in conjunction with the change of the property value.
Thus, the workaround method can be used only if you are sure that the property has a simple setter e.g. property XX: integer read FXX write XX.
The purpose of inc/dec procedure is optimisation and cleaner coding. In this particular case, Tag := tag+1 seems to be cleaner/more readable than the workaround and with no noticeable difference in terms of execution speed.
Nevertheless I have to say that the workaround method is creative and an eye-opener.

[PascalDragon]

It's an honoree compiler ? 

Code: Pascal  [Select][+][-]

1.  Inc(PQWord(@Tag)^);    //For 64 bit systems.
2.  

This is not guaranteed to keep working, because it's undocumented behaviour and will likely be fixed in the future. Always assume that you can't take the address of a property and then you'll be safe.

[jamie]

because it's undocumented behavior and will likely be fixed in the future

Ok, if you want to break a lot of stuff that's fine with me, it's your show.

Btw, Delphi allows this too, and there is lots of code out there that depends on this ability due to remote access of members.

[PascalDragon]

because it's undocumented behavior and will likely be fixed in the future

Ok, if you want to break a lot of stuff that's fine with me, it's your show.

Btw, Delphi allows this too, and there is lots of code out there that depends on this ability due to remote access of members.

The idea of properties is that it doesn't matter for the user whether they're implemented using fields or methods, because the implementer of the class might decide from one day to the other that a method is better than a field and thus this shouldn't break user's code. Thus relying on such an implementation detail of a class is simply wrong and not in the spirit of the feature that is the properties.