www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - byte & byte

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
can someone remind why the resulting type is int?

is it a "c does it" thing?
Oct 27 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Oct 2010 22:49:47 -0400, Ellery Newcomer  
<ellery-newcomer utulsa.edu> wrote:


 can someone remind why the resulting type is int?

 is it a "c does it" thing?



Yes, but it should be reassignable to a byte via range propogation.  With  
C, there was no range propogation, so int & int was also assignable to  
char.

-Steve
Oct 27 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Hm. Thanks for the heads up.

Now how about

byte &= int

is there any good reason why the result type of that isn't error?

On 10/27/2010 10:12 PM, Steven Schveighoffer wrote:

 On Wed, 27 Oct 2010 22:49:47 -0400, Ellery Newcomer
 <ellery-newcomer utulsa.edu> wrote:


 can someone remind why the resulting type is int?

 is it a "c does it" thing?



 Yes, but it should be reassignable to a byte via range propogation. With
 C, there was no range propogation, so int & int was also assignable to
 char.

 -Steve
Oct 27 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Next question:

why does

(~ short) result in short, but in c it results in int?

On 10/27/2010 11:02 PM, Steven Schveighoffer wrote:

 Well, if 'int' represents a literal, or a manifest constant, they are
 not exactly ints. When the compiler can tell that the result of the
 operation will fit into a byte, it allows it to go through. I believe
 when it can't tell, it should error, but &= may be a special case, I'm
 not sure.

 -Steve
Oct 28 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Ellery Newcomer Wrote:


 Next question:
 
 why does
 
 (~ short) result in short, but in c it results in int?



I see no reason for this or byte & byte to return an int. Since this would only
cause C code to not compile, why not change it?
Oct 28 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
erm, wut?

On 10/28/2010 12:56 PM, Jesse Phillips wrote:

 I see no reason for this or byte&  byte to return an int. Since this would
only cause C code to not compile, why not change it?
Oct 28 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Ellery Newcomer Wrote:


 erm, wut?
 
 On 10/28/2010 12:56 PM, Jesse Phillips wrote:

 I see no reason for this or byte&  byte to return an int. Since this would
only cause C code to not compile, why not change it?






This should compile:

void main() {
   byte a = 5;
   byte b = 10;
   short c = 9;

   auto i = 5 & 10;
   auto j = ~c

   assert(typeof(i) == typeid(byte));
   assert(typeof(j) == typeid(short));
}

Because C code will not behave differently and since it is a smaller type it
can only cause C code not to compile. And in reality it the change should only
effect D code that uses type inference, but will not result in any broken code
since byte is implicitly an int.
Oct 29 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 10/29/2010 10:48 AM, Jesse Phillips wrote:

 Because C code will not behave differently



I'm not convinced of this. Proposed counterexample:

// test.d
import std.stdio;
void main(){
   ushort x = 0xffff;
   writefln("%08x", ~x+1u);
}


// test.c
#include <stdio.h>
void main(void){
   unsigned short x = 0xffff;
   printf("%08x", ~x+1u);
}
Oct 29 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Ellery Newcomer Wrote:


 On 10/29/2010 10:48 AM, Jesse Phillips wrote:

 Because C code will not behave differently



 I'm not convinced of this. Proposed counterexample:
 
 // test.d
 import std.stdio;
 void main(){
    ushort x = 0xffff;
    writefln("%08x", ~x+1u);
 }



http://ideone.com/OsbTE


 // test.c
 #include <stdio.h>
 void main(void){
    unsigned short x = 0xffff;
    printf("%08x", ~x+1u);
 }



http://ideone.com/4S4QO

Ok, truly not what I was thinking would happen. I believe D's behavior to be
correct, but as it is the exact same code I think it is worthy of a bug report.
Oct 29 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
It all depends on how important backwards compatibility with C is (I 
wish it weren't important).

 From a machine code point of view, D's behavior probably makes more 
sense, at least with intel.

http://d.puremagic.com/issues/show_bug.cgi?id=5132

On 10/29/2010 01:52 PM, Jesse Phillips wrote:

 Ok, truly not what I was thinking would happen. I believe D's behavior to be
correct, but as it is the exact same code I think it is worthy of a bug report.
Oct 29 2010
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Ellery Newcomer Wrote:


 It all depends on how important backwards compatibility with C is (I 
 wish it weren't important).



I know, in this case it would seem odd to rely on such behavior of C (I expect
such operations are generally placed in a short and thus does not care what
happens as an int)

But I do understand the desire behind the rule. I mean it is much easier to
convert C when you have the compiler yelling at you.
Oct 29 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 27 Oct 2010 23:34:04 -0400, Ellery Newcomer  
<ellery-newcomer utulsa.edu> wrote:


 Hm. Thanks for the heads up.

 Now how about

 byte &= int

 is there any good reason why the result type of that isn't error?



Well, if 'int' represents a literal, or a manifest constant, they are not  
exactly ints.  When the compiler can tell that the result of the operation  
will fit into a byte, it allows it to go through.  I believe when it can't  
tell, it should error, but &= may be a special case, I'm not sure.

-Steve
Oct 27 2010