Re: generalized lvalues

[Ziemowit Laski <zlaski@apple.com>]

On 19 Nov 2004, at 17.40, Joe Buck wrote:

> On Fri, Nov 19, 2004 at 05:29:27PM -0800, Ziemowit Laski wrote:
>> What I was hoping for is that we can turn
>>
>>         (cast)expr = ...
>>         *(cast)expr)++
>> into
>>
>>         *((cast *)&expr) = ...
>>         *((cast *)&expr)++
>>
>> when -fassign-to-cast is specified.
>
> So, it appears that you want to turn (cast)expr into *((cast *)&expr).
> You still have the issue with C++ overloading; since it is an lvalue,
> if you have
>
> void func(cast&);
> void func(const cast&);
>
> then
>
> func((cast)expr) will call the wrong function, because with your rule,
> func(cast&) gets called, while with the ISO C++ rule, func(const cast&)
> gets called.
>
> Now, you could get around this if you can specify a rule that explains
> which casts get transformed and which don't.

Only casts that are assigned to (or incremented or decremented) would 
be transformed,
and so only if _those_ casts are subsequently referenced do we run into 
the problems
you describe.  The 'func((cast)expr)' example you describe will be 
untouched.

To put it another way, I'm only concerned with cases where the compiler 
currently complains
about assigning to a non-lvalue, and the non-lvalue in question is a 
cast of an lvalue.

--Zem