On 05/16/2013 04:17 PM, Mr. Anonymous wrote: > On Thursday, 16 May 2013 at 21:04:38 UTC, Jonathan M Davis wrote: >> On Thursday, May 16, 2013 22:42:23 luka8088 wrote: >>> I agree that it is exactly the same as checking if (text1.length > >>> text2.length). And I don't think that this is an issues if you are aware >>> of the fact that you are working with unsigned values. But in the code >>> that I wrote there was no mentioning of unsigned so the possibility of >>> that kind of issue never came to mind until I actually printed the >>> values. And that is what I wanted to emphasize. >> >> Well, I'm not sure what can be done about that. length is size_t, >> which is the >> unsigned integral value which matches the architecture (uint for >> 32-bit and >> ulong for 64-bit). AFAIK, the documentation is clear on this (though I >> haven't >> read it recently). If it's not, then it should be made clearer, but using >> size_t for length is pervasive in D as it is in C++, and if you know the >> standard types, you know what size_t is. >> >> As for overflow checking, it's come up quite a few times, and Walter is >> completely against it. The hardware doesn't support it, and it would >> definitely >> be slow if it were added. The standard way to handle that if you want >> it is to >> create user-defined integral type which does the checks (though that >> obviously >> won't help you when you can't control the types that you're dealing >> with). But >> if you want to add checks in your code, you can always create a wrapper >> function for doing the subtraction. And if you wanted the checks to >> only be >> there in non-release mode, then you could even put the checks in a >> version(assert) block. So, you can add checks if you want them, but >> there's >> pretty much no way that how unsigned or overflow are handled in the >> language >> is going to change. >> >> - Jonathan M Davis > > I agree with Walter if we're talking about production code, but I think > it could be very helpful for debug builds. > > P.S. >> The hardware doesn't support it > That's not completely true. > e.g. x86, while it doesn't throw an exception on an overflow, it does > set a flag, which could be relatively cheaply checked.
Perhaps a compiler flag would be nice, can't really argue performance if it's explicitly chosen. Like -profile or -cov.
signature.asc
Description: OpenPGP digital signature
