• Renoir (10/10) Jun 11 2011 Sorry for the question but i'm an absolutely noob
• Jonathan M Davis (7/21) Jun 11 2011 All integral operations where the types are int or smaller result in an ...
• Steven Schveighoffer (5/28) Jun 11 2011 If I'm not mistaken, the original code should be handled (and compile
• Jonathan M Davis (10/41) Jun 11 2011 No. As I understand it, some of the simple cases have been (though you w...
• bearophile (4/8) Jun 12 2011 I am not sure D range propagation is supposed to work across different l...
• Jonathan M Davis (4/12) Jun 12 2011 I'm pretty sure that it is (it wouldn't be worth much if it didn't IMHO)...
• Don (3/16) Jun 12 2011 Bearophile is right. It only applies to single expressions. (Using more
• Timon Gehr (7/17) Jun 11 2011 Yes, the compiler casts all operands to 'int' when performing arithmetic...
• renoir (6/6) Jun 11 2011 Ok.
• Jonathan M Davis (9/17) Jun 11 2011 That would depend entirely on the optimizer. I believe that the cast is
• bearophile (4/5) Jun 12 2011 You have to take a look at the asm produced by the compiler to be sure w...

Renoir <csharp relhost.net> writes:

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?

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

Don <nospam nospam.com> writes:

Jonathan M Davis wrote:
 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

Bearophile is right. It only applies to single expressions. (Using more 
than one statement requires flow analysis).

Timon Gehr <timon.gehr gmx.ch> writes:

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

renoir <csharp relhost.net> writes:

Ok.

So i can do:

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

is there any difference in terms of performance?

Thx.

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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