www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Sharing InRange.d - (just in case I'm not the only one)

reply David L. Davis <SpottedTiger yahoo.com> writes:
Well, I'm beginning to find it a pure headache when I pass different numeric
datatyes into general template functions, and trying to compare them against one
another. And since I mainly work in Visual Basic v6.0 (in which all numerics
types are signed) for a living, I never thought that comparing a long to an
ulong, or other signed to unsigned combos would be the slightest problem. Well,
I guess I've learned my lesson the hard way, and that's D is a lot like C in
this area, maybe it will get better with numeric compares in the future. <g>

Anyway, to pull my fat out of the fire, I've created two templates I'm going to
add to my three or four projects that will pretty much fail on negative values
(to my surprise!! For sure going forward, I will be adding a lot more unittests
against negative values in the future.). 

So, I'd like to post them here, just in case someone else might like to use
them. And for those who work in a C-like language daliy, this probably isn't
even an issue. :P






























































































































































































David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Sep 08 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Sorry for top-posting, but my comment is buried in the code below...

David L. Davis wrote:

 Well, I'm beginning to find it a pure headache when I pass different numeric
 datatyes into general template functions, and trying to compare them against
one
 another. And since I mainly work in Visual Basic v6.0 (in which all numerics
 types are signed) for a living, I never thought that comparing a long to an
 ulong, or other signed to unsigned combos would be the slightest problem. Well,
 I guess I've learned my lesson the hard way, and that's D is a lot like C in
 this area, maybe it will get better with numeric compares in the future. <g>
 
 Anyway, to pull my fat out of the fire, I've created two templates I'm going to
 add to my three or four projects that will pretty much fail on negative values
 (to my surprise!! For sure going forward, I will be adding a lot more unittests
 against negative values in the future.). 
 
 So, I'd like to post them here, just in case someone else might like to use
 them. And for those who work in a C-like language daliy, this probably isn't
 even an issue. :P
 





































This portion is incorrect:






















The code you 'borrowed' from std.math.signbit is valid only for an IEEE 
floating point value, not for ints, longs, shorts, etc.  With the 
integer types (and possibly the floating point types, I'm not sure) 
there is the endianness issue.

Get someone with a big-endian machine to run your unittests, compiled 
with GDC.  It should work fine on an X86 arch PC.  However, I can almost 
guarantee your code will fail on a PPC or Sun box.  I don't have any of 
those myself, so I can't test.









































































































































 
 David L.
 
 -------------------------------------------------------------------
 "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
 -------------------------------------------------------------------
 
 MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html



-- 
Regards,
James Dunne
Sep 12 2005
next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
James thanks for your input, my comments are below. ;)

In article <dg5ema$c2a$1 digitaldaemon.com>, James Dunne says...

This portion is incorrect:






















The code you 'borrowed' from std.math.signbit is valid only for an IEEE 
floating point value, not for ints, longs, shorts, etc.  With the 
integer types (and possibly the floating point types, I'm not sure) 
there is the endianness issue.


Umm! The negative (which is one bit) is always in the high-ordered byte on the
x86 CPU which stores them in a reverse order within memory (I did some assembly
in my more youngful days), and it doesn't seem to matter if it's an integer or a
float for this 'bit' of information. Below I did some code to show what I mean
using the borrowed code from std.math.signbit, showing 'byte' all the way to the
'ireal' datatypes:




































































































<This was the output, but the message would not post with it in!?!>


Get someone with a big-endian machine to run your unittests, compiled 
with GDC.  It should work fine on an X86 arch PC.  However, I can almost 
guarantee your code will fail on a PPC or Sun box.  I don't have any of 
those myself, so I can't test.
 
Regards,
James Dunne


Yeah, I'm pretty sure you're right that this will only work only on a Intel
x86-like CPU...I should've put that into the comments. In fact, I'll start
adding a "Source Platform" and a "Target Platform" entrys into my future
comments. 

Of course, I'd love to know how to setup this code to also run on a big-endian
machine and such. So, maybe someone reading this could help me out in this area
and show some example code (version statements wrappers that would work), and
also run the code on a non-Intel box to test it out.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Sep 14 2005
prev sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <dg5ema$c2a$1 digitaldaemon.com>, James Dunne says...

 ...























 ...

Get someone with a big-endian machine to run your unittests, compiled 
with GDC.  It should work fine on an X86 arch PC.  However, I can almost 
guarantee your code will fail on a PPC or Sun box.  I don't have any of 
those myself, so I can't test.

 ...

Regards,
James Dunne


I've looked into what's the different between little-endian (Intel x86 /
Windows, Linux) and big-endian (PPC / Mac OS, Linux, Unix) and it appears if I
understand it correctly, that only the byte order from the most significant to
the least significant are stored in memory the opposite way (but the bits remain
in the same order).

If that's so, then shouldn't the simple version statement I've placed in the
code below solve this issue?






























































David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Sep 19 2005