Re: [avr-gcc-list] compilation results with avr-gcc 4.8.3

[David Brown]

On 26/09/14 10:44, Richard Weickelt wrote:
> Hi,
> 
>>> Is it fair to conclude that the ~
>>> operator, applied to an unsigned char, does produce an int as output
>>> instead of the input type?
>>
>> Yes, this is exactly what the C standard promotion rules require.
>>
>> Well, to be exact, they *require* it behaves "as if" it were promoted
>> to "int", so if the sign extension has no net effect to the result, it
>> might be left out as well.  So in that sense, it might be considered a
>> "missed optimization" bug in GCC here, but it's probably always hard
>> to catch all those situations well were the integer promotion could be
>> bypassed.
> 
> I remember vaguely somebody's proposal on this list to write a C++ class for
> unsigned char in order to "bypass" promotion rules. Has anyone tried that?
> Just being curious.
> 
> Richard
> 

I remember vaguely trying that myself.  My memory is so vague that I
can't tell you if I was inspired by the same list poster you remember,
or if I /was/ that list poster...

Certainly I did not get very far with it at the time - it was hard to
get a class that had convenient conversions and interaction with other
numeric types while avoiding accidental ones that spoil the point.  And
while it helped for some code, it also made other code worse.

I suspect that C++11's explicit conversion operators could help here -
maybe it is time to revisit the idea with a newer avr-gcc.  Certainly I
think C++ has been much improved with C++11, and it is a more suitable
for small embedded development now.

I haven't done much with the AVR for a while now, however - so don't
hold your breath waiting for me to try it.