Quote
Yeah, sure, I do this kind of thing sometimes, but it is not practical,
and since floats often do work, that is what I usually end up using,
especially considering the legacy of code that uses floats. it is just
maddening when it stops working for absolutely no reason -- I must have
just looked at it wrong while it was compiling, and so it got offended
or something...
We had a bunch of products using Interbase. I used this technique because
Interbase and floating point numbers can be a little unpredictable,
especially when using UDF's. It works well, solong as your calculations are
to a specific amount of decimal places. Things like fixed percentages (e.g.
Each transaction requires a 4.5% cut to be paid to a specific account.) I
wouldn't have used this technique if Interbase hadn't messed with me a lot.
As for assignments... I have found that Single is extermemly bad at accepting
specific values. Double is a lot better, but I still tend to assign "0.0000"
rather than just "0" and often assigning just 0 gives the weird results you
mention. it is definately related to 0 though. Assigning whole numbers seems
to work in a reliable way.
Though, dotNet isn't much better. Passing "TDateTimes" to and from dotNet
via PInvoke gives really, really odd results. I had a DLL for a third party
product that interfaces with hardware. Its interface was written in Delphi
and used Shortstrings and TDateTimes in the API (shudder.) This causes some
issues when you need to call those API routines from C# ;-) The Shortstrings
weren't too bad (you need to shift the C# string along one char and add the
length cast to a char - pretty much - and truncate to 255 chars.) However,
TDateTime is a PITA. You can quite easily get a TDateTime alike using the
COM compatible DateTime conversion routine, but when you pass that to
Delphi, there are some odd rounding errors. it is out by something like
0.0000000052 or something equally small. This turns out to be Miliseconds,
so if you remove the partial seconds, it is all fine. All I know is, if you
view the value in VS2005, it looks to the same precision ans in Delphi, but
in reality it is not. I guess I could have written a wrapper and marshalled
the dotNet type (using DateTime.Ticks or something like that), but adding an
extra layer was not the idea! It now works well enough to be passable.The
device only time stamps in 15 second blocks anyway, so it is all fine in the
end. Just very, very perplexing. (This is an unknown version of Delphi's DLL
talking to dotNet 2.0, by the way.)
