Hi there

I have been told that this test shouldnt work:

void __fastcall setTestWidth(int Value){Width = Value;}
int  __fastcall getTestWidth(){return Width;}

__property int TestWidth = {read=getTestWidth, write=setTestWidth};

void __fastcall TForm1::Button3Click(TObject *Sender)
{
   TestWidth++;   
}
//-------------------------------------------------------

But it does!
 
Anybody who can tell me if this is just luck ?

Another thing:
Is there any speed penalty to using properties or is the
compiler smart enough to use the original variable.
I am thinking about e.g. private   int FWidth   in the base 
class, but in decadents it is accesd by the property Width.

__property int Width = {read=FWidth};

I can emagine that if there is a getter function doing stuff
there would of course be a penalty.

Thanks in advance
Kind regards
Asger

Asger Joergensen schreef:
> Hi there
> 
> I have been told that this test shouldnt work:
> 
> void __fastcall setTestWidth(int Value){Width = Value;}
> int  __fastcall getTestWidth(){return Width;}
> 
> __property int TestWidth = {read=getTestWidth, write=setTestWidth};
> 
> void __fastcall TForm1::Button3Click(TObject *Sender)
> {
>    TestWidth++;   
> }
> //-------------------------------------------------------
> 
> But it does!
Probably because in this case the ++ is a build in operator for which 
code is generated directly and the compiler does the right thing.

An example which I know not to work is

Font->Style << fsBold;

In this case the Style property return a temporary. On this temporary 
the opreator<< method of the Set class is called which modifies the 
temporary. Finally the temporary is destroyed without writing back the 
changes.

Correct this by doing:

Font->Style = Font->Style << fsBold;

Probably the ++ won't work either when it is a custom operator.

Eelke

Hi Clayton
 
Thanks for explaining.

Happy New Year
Kind regards
Asger

> Anybody who can tell me if this is just luck ?

I have seen many posts over the years saying that this doesn't work.  I 
believe the correct answer is it *sometimes* doesn't work so therefor don't 
do it.  In your particular case the compiler is smart enough to generate 
code that performs a call to getTestWidth, stores the result in a register, 
increments the value, and calls setTestWidth to stuff the new value back in.

> Is there any speed penalty to using properties or is the
> compiler smart enough to use the original variable.
> I am thinking about e.g. private   int FWidth   in the base
> class, but in decadents it is accesd by the property Width.
>
> __property int Width = {read=FWidth};

No speed penalty.  FWidth is accessed directly.

To test these yourself create your program and set a break-point on the line 
you want to inspect.  When program execution breaks turn on CPU view 
(ALT+CTL+C) and look at what the compiler generated.

Clayton