From: lisch.at.tempest-sw.com@nojunkmail.com (Ray Lischner) Subject: Re: comp vs. int64 (was bug with comp) Date: 13 Jan 2000 00:00:00 GMT Message-ID: Content-Transfer-Encoding: 7bit References: <387C021A.4675DAD5@nwu.edu> <2a6p7soe38upd4tl6nda04rc069edl9ns1@4ax.com> <387D4C91.98BD85EC@nwu.edu> <2eqr7skpm3fd7m9of9eg7775f9ofk74nng@4ax.com> <387E2390.63E61CB3@nwu.edu> Organization: Tempest Software, Inc., Corvallis, Oregon Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Newsgroups: comp.lang.pascal.delphi.misc X-Complaints-To: newsabuse@supernews.com On Thu, 13 Jan 2000 13:12:16 -0600, Robert Lee wrote: >BTW, I find it ammusing that the helps claims that you should switch >from comp to int64 for "better performance" There are three reasons to use Int64 instead of Comp: 1. Converting to a string works with Int64, but not with Comp. For reasons that escape me, Delphi's floating point to string formatting functions have a hardwired limit of 18 digits of precision, despite the fact that the maximum decimal precision of Comp, Extended, and Currency is 19 digits. 2. Int64 is not subject to the vagaries of the floating point control word. Some Microsoft functions and DLLs arbitrarily change the FPU control word. If the precision is set to single or double instead of extended, the precision of Comp (and Currency) suffer. The workaround (if you must use Comp or Currency) is to use SafeLoadLibrary instead of LoadLibrary, and to check your results carefully and thoroughly. 3. Int64 supports integer operators, such as shl and shr. As has been mentioned elsewhere in this thread, you can use Comp for arithmetic (if you know the FPU precision is extended), and cast to Int64 for converting to a string or performing a shift or bitwise operation. -- Ray Lischner, http://www.tempest-sw.com/nutshell author of Delphi in a Nutshell