Re: Access original data from array
On Thu, 01 Oct 2009 05:02:10 +0100, Tom S wrote: Moritz Warning wrote: Hi, how can I access the original value for xs? [..] You were probably looking for the old meaning of .init, but it's gone now, so I present these alternative fixes: 1) You need to load the state of the game from before overriding xs. I recommend Quick Save and Quick Load. Often bound to F5 and F9. I tried F5 and F9, but I only accidently activated the bonus level. Quirky game... 2) Perhaps a custom-fit Delorian will do. - A FluxCapacitator would be an overkill solution. - I don't do coding while driving at 88Mph. 3) If all else fails, I'm afraid you'll have to resort to copying the contents of xs prior to overwriting them. I will give it a try. Thanks!
Re: implicit ubyte casting
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
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;i10;i++);//ubyte nloop is created quite a few lines above. Then why use an ubyte instead of a byte or an int? You could also just do: for(int i = cast(byte)nloop; i 10; i++) Jeremie
Re: implicit ubyte casting
Jeremie Pelletier wrote Then why use an ubyte instead of a byte or an int? I wasn't me who wrote that part of the code :) You could also just do: for(int i = cast(byte)nloop; i 10; i++) I forgot the minus sign: for(int i = -cast(int)nloop;i 10; i++) Still think it is unnecessary bug-prone.
Re: implicit ubyte casting
Moritz Warning wrote This is a troublesome behavior: ubyte z = 5; int x = -z; // x now is 251 int y = -1 * z; // y is now -5 Yes, troublesome is the correct word :) Does anybody ever use the =-z behaviour?
Re: implicit ubyte casting
Saaa: Does anybody ever use the =-z behaviour? Sometimes C programmers use something like: unsigned int x = -1; The interaction of signed-unsigned integral numbers in D is very error-prone, so much that I suggest to use unsigned integrals in D only where strictly necessary (generally when you need bitfields for bitwise operations (so not for arithmetic operations), or the less common situations where you need the full range of 1,2,4,8 bytes). Sometimes I even cast array lengths to an int and then I keep and use only such int around because in D that's safer than using a size_t (example: if you compare an unsigned int length with a negative int, your code will have a bug). I have discussed such topics several times in the main D newsgroup, and in the end no good solution has being found/accepted so far. But eventually some better solution must be found... Bye, bearophile
Re: implicit ubyte casting
On Thu, Oct 1, 2009 at 2:00 PM, bearophile bearophileh...@lycos.com wrote: I have discussed such topics several times in the main D newsgroup, and in the end no good solution has being found/accepted so far. But eventually some better solution must be found... Fucking A, bearophile. Bugzilla. How many fucking times do we have to tell you.
Re: implicit ubyte casting
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. But the counter argument that will likely come up is generic behavior. So, to prempt that.. does unary minus have any useful meaning for MOST types? My answer is still no. :) Later, Brad
