Sorry for the question but i'm an absolutely noob
I have:

byte x = 10;
byte y = 3;
x = x + y;

why compilers complains?

Error: cannot implicitly convert expression (cast(int)x + cast(int)
y
) of type int to byte

Have i to make another cast to sum byte + byte?

On 2011-06-11 14:54, Renoir wrote:
> Sorry for the question but i'm an absolutely noob
> I have:
> 
> byte x = 10;
> byte y = 3;
> x = x + y;
> 
> why compilers complains?
> 
> Error: cannot implicitly convert expression (cast(int)x + cast(int)
> y
> ) of type int to byte
> 
> Have i to make another cast to sum byte + byte?

All integral operations where the types are int or smaller result in an int (unless you're dealing with unsigned types, in which case, I believe that the result would be uint). So, in this case the result of x + y is int. So, if you want the result to be byte, you have to do

x = cast(byte)(x + y);

- Jonathan M Davis

Renoir wrote:
> Sorry for the question but i'm an absolutely noob
> I have:
>
> byte x = 10;
> byte y = 3;
> x = x + y;
>
> why compilers complains?
>
> Error: cannot implicitly convert expression (cast(int)x + cast(int)
> y
> ) of type int to byte
>
> Have i to make another cast to sum byte + byte?

Yes, the compiler casts all operands to 'int' when performing arithmetics. You can explicitly cast it back, or you can do:

x = (x+y) & 0xff;

shorter, safer and nicer in general.

If you compile with -O, this won't even have an overhead.


Timon

Ok.

So i can do:

x = cast(byte)(x + y);
x = (x + y) & 0xff;

is there any difference in terms of performance?

Thx.

On 2011-06-11 16:43, renoir wrote:
> Ok.
> 
> So i can do:
> 
> x = cast(byte)(x + y);
> x = (x + y) & 0xff;
> 
> is there any difference in terms of performance?

That would depend entirely on the optimizer. I believe that the cast is guaranteed to cost nothing. The & might cost something if you don't compile with -O, but even then cost is very small. Ultimately, they're probably the same, but it depends on what exactly the compiler does. Personally, I much prefer the cast because it's more immediately clear to me what you're doing. But if someone uses the & 0xff trick all the time, then that's probably quite clear to them as well.

- Jonathan M Davis

On Sat, 11 Jun 2011 18:32:59 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On 2011-06-11 14:54, Renoir wrote:
>> Sorry for the question but i'm an absolutely noob
>> I have:
>>
>> byte x = 10;
>> byte y = 3;
>> x = x + y;
>>
>> why compilers complains?
>>
>> Error: cannot implicitly convert expression (cast(int)x + cast(int)
>> y
>> ) of type int to byte
>>
>> Have i to make another cast to sum byte + byte?
>
> All integral operations where the types are int or smaller result in an int
> (unless you're dealing with unsigned types, in which case, I believe that the
> result would be uint). So, in this case the result of x + y is int. So, if you
> want the result to be byte, you have to do
>
> x = cast(byte)(x + y);

If I'm not mistaken, the original code should be handled (and compile without errors) by range propagation.  Is that not fully implemented?

-steve

On 2011-06-11 18:54, Steven Schveighoffer wrote:
> On Sat, 11 Jun 2011 18:32:59 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On 2011-06-11 14:54, Renoir wrote:
> >> Sorry for the question but i'm an absolutely noob
> >> I have:
> >> 
> >> byte x = 10;
> >> byte y = 3;
> >> x = x + y;
> >> 
> >> why compilers complains?
> >> 
> >> Error: cannot implicitly convert expression (cast(int)x + cast(int)
> >> y
> >> ) of type int to byte
> >> 
> >> Have i to make another cast to sum byte + byte?
> > 
> > All integral operations where the types are int or smaller result in an
> > int
> > (unless you're dealing with unsigned types, in which case, I believe
> > that the
> > result would be uint). So, in this case the result of x + y is int. So,
> > if you
> > want the result to be byte, you have to do
> > 
> > x = cast(byte)(x + y);
> 
> If I'm not mistaken, the original code should be handled (and compile without errors) by range propagation. Is that not fully implemented?

No. As I understand it, some of the simple cases have been (though you would have thought that this would qualify as a simple case), but IIRC, when it came up recently, Don said that it wasn't fully implemented yet. I'm not quite sure which parts of it have been and haven't been implemented though.

Certainly, once range propagation has been fully implemented, this particular will work without needing any casts, but as soon as the compiler doesn't know what the values of x and y are, I believe that it would still end up complaining.

- Jonathan M Davis

Jonathan M Davis:

> That would depend entirely on the optimizer.

You have to take a look at the asm produced by the compiler to be sure what its optimizations have done.

Bye,
bearophile

Jonathan M Davis:

> Certainly, once range propagation has been fully implemented, this particular will work without needing any casts, but as soon as the compiler doesn't know what the values of x and y are, I believe that it would still end up complaining.

I am not sure D range propagation is supposed to work across different lines of code (I think not).

Bye,
bearophile

On 2011-06-12 02:37, bearophile wrote:
> Jonathan M Davis:
> > Certainly, once range propagation has been fully implemented, this particular will work without needing any casts, but as soon as the compiler doesn't know what the values of x and y are, I believe that it would still end up complaining.
> 
> I am not sure D range propagation is supposed to work across different
> lines of code (I think not).

I'm pretty sure that it is (it wouldn't be worth much if it didn't IMHO), but I'd have to look up discussions on it to be sure.

- Jonathan M Davis