Properties don't behave like variables?

Iain Buclaw ibuclaw at ubuntu.com
Mon May 7 16:02:54 PDT 2012


On 7 May 2012 23:43, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 05/08/12 00:32, Iain Buclaw wrote:
>> On 7 May 2012 23:23, Artur Skawina <art.08.09 at gmail.com> wrote:
>>>> On 2012-05-07 21:53, Steven Schveighoffer wrote:
>>>>
>>>>> How do you overload the operator for a property? For example:
>>>
>>> It can of course be done [1], but i think the question was whether the
>>> compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'.
>>> Unconditionally, as not doing it every time would be confusing and lead
>>> to bugs where the setter gets bypassed.
>>> But what about the case where you want to return a ref to /different/
>>> objects? I guess mandating a setter wouldn't be problem, and still better
>>> than the alternative.
>>>
>>> artur
>>>
>>> [1] I shouldn't even be posting this, as someone might actually think about
>>> using something like it...
>>>
>>>   struct S {
>>>      int i;
>>>      @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
>>>   }
>>>
>>>   int main()
>>>   {
>>>      S s;
>>>      s.p |= 2;
>>>      return s.p;
>>>   }
>>>
>>>   struct PropProxy(RT, string sym) {
>>>      @property ref data() { return *cast(RT*)&this; }
>>>      @property ref get() { return __traits(getMember, data, sym); }
>>>      alias get this;
>>>      auto opOpAssign(string op, T)(T b) {
>>>         return mixin("data." ~ sym ~ " " ~ op ~ "= b");
>>>      }
>>>   }
>>>
>>> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just
>>> out of curiosity, to check if GDC would be able to turn it all into
>>> "mov $0x2, %eax; ret;". ;)
>>>
>>
>> Your wishful thinking serves you well. :-)
>>
>
> Just to make it clear - the above results in:
>
> 08049e50 <_Dmain>:
>  8049e50:       55                      push   %ebp
>  8049e51:       b8 02 00 00 00          mov    $0x2,%eax
>  8049e56:       89 e5                   mov    %esp,%ebp
>  8049e58:       5d                      pop    %ebp
>  8049e59:       c3                      ret
>
> and i believe that after Iain's recent GDC ABI changes the frame pointer
> manipulation is gone, so it all *really* compiles down to just one instruction.

Frame pointer manipulation only now occurs on x86 for functions that
compile in inline assembler (but not GCC inline assembler, and not
naked functions).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


More information about the Digitalmars-d mailing list