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