Re: implicit ubyte casting
Stewart Gordon wrote:
#include
int main() {
unsigned char z = 5;
int x = -z; // x now is 251
Needless to say, this comment is a mistake.
Stewart.
Re: looking for an IDE
Phil Deets Wrote: > Is there a Windows IDE with support for D2 debugging, > building, The Zeus IDE can be easily configured to run the D compiler or any of the build tools: http://www.zeusedit.com/forum/viewtopic.php?t=2465 > and basic code navigation (such as go to definition)? Zeus comes with a modified version of ctags meaning it can generate tag information for the D language. This tag information is used to drive the code navigation, class browsing and intelisensing features. I made these ctags changes quite some time ago changes when there was no D2 so I am not sure if this tagger stil works for D2. For any one that is inerested her are my ctags code changes: htp://www.zeusedit.com/z300/ctags_src.zip NOTE: Zeus is shareware Jussi Jumppanen Author: Zeus IDE
Re: implicit ubyte casting
Moritz Warning wrote:
ubyte z = 5;
int x = -z; // x now is 251
int y = -1 * z; // y is now -5
Indeed, I've just looked at the spec, and it appears that the promotion
of all smaller integer types to int/uint applies only to binary
operations. Why?
It even arguably breaks the "looks like C, acts like C" principle (which
I thought was the reason behind these promotions in D):
--
#include
int main() {
unsigned char z = 5;
int x = -z; // x now is 251
int y = -1 * z; // y is now -5
printf("%d %d %d\n", z, x, y);
return 0;
}
--
5 -5 -5
--
(DMC 8.42n Win)
Stewart.
Re: implicit ubyte casting
On Fri, 02 Oct 2009 16:25:01 +0200, Don wrote:
> Brad Roberts wrote:
>> On Thu, 1 Oct 2009, Saaa wrote:
>>
>>> I think is very bug-prone, isn't it obvious iub should be -5?
>>>
>>> ubyte ub = 5;
>>> int iub = -ub; // iub now is 251
>>>
>>> What is the reasoning to do it this way?
>>
>> The inclusion of the 'int' part obscures what I think the real problem
>> is..
>>
>>Does it make sense to use uniary-minus on a unsigned type?
>>
>> My answer.. no.
>
>
> I agree. But you don't actually need unary minus to see the problem:
>
> import std.stdio;
>
> void main()
> {
>uint a = 0;
>uint b = 5;
>long ib = a - b;
>writefln("%s", ib); // prints: 4294967291
> }
I feel like walking on the edge of a cliff all time without noticing. :>
Re: implicit ubyte casting
Brad Roberts wrote:
On Thu, 1 Oct 2009, Saaa wrote:
I think is very bug-prone, isn't it obvious iub should be -5?
ubyte ub = 5;
int iub = -ub; // iub now is 251
What is the reasoning to do it this way?
The inclusion of the 'int' part obscures what I think the real problem
is..
Does it make sense to use uniary-minus on a unsigned type?
My answer.. no.
I agree. But you don't actually need unary minus to see the problem:
import std.stdio;
void main()
{
uint a = 0;
uint b = 5;
long ib = a - b;
writefln("%s", ib); // prints: 4294967291
}
Re: implicit ubyte casting
Jeremie Pelletier wrote: Don wrote: Saaa wrote: Jeremie Pelletier wrote Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? Minus toggles the most significant bit, be it on a signed or unsigned type. When converting it to an int, the byte being signed or unsigned does make a difference: when unsigned the number is copied as is, when signed the most significant bit (bit 7) is shifted to the most significant bit of the int (bit 31). Its therefore pretty standard logic, no warning is given since the entire ubyte range fits within an int Jeremie Thanks, but it is not that I do not know how it occurs more that I should have asked whether people use this kind of logic. For me it resulted in annoying bug like this: for(int i = nloop;i<10;i++);//ubyte nloop is created quite a few lines above. This has been discussed before, and it really should be an error. It's reasonable to implicitly cast between integral types of different size, and also signed<->unsigned, but performing both within the same expression is almost always a bug. It should not be possible without an explicit cast. I know VC++ shouts a warning everytime signed and unsigned integrals are mixed, maybe that's the road D should take too. We can do *much* better than that. About two releases ago D2 got integer range tracking, so you can do things like: long a = someCrazyFunction(); ubyte b = (a & 7) | 0x60; // No worries! This is perfectly fine! ubyte c = a; // Error, might overflow. It just needs to be extended a bit more. It's far from finished.
Re: implicit ubyte casting
Don wrote: Saaa wrote: Jeremie Pelletier wrote Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? Minus toggles the most significant bit, be it on a signed or unsigned type. When converting it to an int, the byte being signed or unsigned does make a difference: when unsigned the number is copied as is, when signed the most significant bit (bit 7) is shifted to the most significant bit of the int (bit 31). Its therefore pretty standard logic, no warning is given since the entire ubyte range fits within an int Jeremie Thanks, but it is not that I do not know how it occurs more that I should have asked whether people use this kind of logic. For me it resulted in annoying bug like this: for(int i = nloop;i<10;i++);//ubyte nloop is created quite a few lines above. This has been discussed before, and it really should be an error. It's reasonable to implicitly cast between integral types of different size, and also signed<->unsigned, but performing both within the same expression is almost always a bug. It should not be possible without an explicit cast. I know VC++ shouts a warning everytime signed and unsigned integrals are mixed, maybe that's the road D should take too.
Test - ignore - browser problems
Testing 1, 2, 3, testing
Re: implicit ubyte casting
Saaa wrote: Jeremie Pelletier wrote Saaa wrote: I think is very bug-prone, isn't it obvious iub should be -5? ubyte ub = 5; int iub = -ub; // iub now is 251 What is the reasoning to do it this way? Minus toggles the most significant bit, be it on a signed or unsigned type. When converting it to an int, the byte being signed or unsigned does make a difference: when unsigned the number is copied as is, when signed the most significant bit (bit 7) is shifted to the most significant bit of the int (bit 31). Its therefore pretty standard logic, no warning is given since the entire ubyte range fits within an int Jeremie Thanks, but it is not that I do not know how it occurs more that I should have asked whether people use this kind of logic. For me it resulted in annoying bug like this: for(int i = nloop;i<10;i++);//ubyte nloop is created quite a few lines above. This has been discussed before, and it really should be an error. It's reasonable to implicitly cast between integral types of different size, and also signed<->unsigned, but performing both within the same expression is almost always a bug. It should not be possible without an explicit cast.
