Am 17.11.2011 20:51, schrieb Seth Grover:
>
> Although I can avoid the problem by casting the longword to a double
How should the compiler know that the division should be done using
double? Using always double slows down calculations. Because the range
of longword fits into a single as well as 2
On 17 November 2011 21:51, Seth Grover wrote:
> For what it's worth, in C (compiled with gcc) both
> 64-bit and 32-bit give the same (correct) answer, 733682.6250.
>
For what it's worth, a Java test (compiled under 64-bit Linux) also
gives the answer of 733682.6250.
--
Regards,
- Graeme -
In a project I'm working on making platform portable, I was getting a
different answer for a calculation on i386 vs. x86_64. I boiled it
down to this:
===
program project1;
{$mode objfpc}{$H+}
uses
Classes,
SysUtils;
var
iHour : longword;
r64 : double;
begin
On Wed, Nov 16, 2011 at 5:05 PM, Sven Barth wrote:
> Google does not state that its OS is Linux compatible, thus in theory they
> can add, modify or delete syscalls of the OS. While an addition is no
> problem for FPC and its RTL, a modification or deletion is.
I decided to ask Google what they t
In our previous episode, Sven Barth said:
> > Is there a general type dedicated for being able to hold any encoding ?
> > (be it ANSIxyz, UTF-8 or UTF-16) ?
>
> In theory the AnsiString type (which is now the code page aware string
> type) should be capable of holding UTF-8 and UTF-16 data, but e
Am 17.11.2011 12:59, schrieb Michael Schnell:
Note that the Delphi2009 definition is theoretically capable of
combining one and
two bytes in one type (like Yury's).
As I don't have such a Delphi please help me to understand:
Is there a general type dedicated for being able to hold any encoding
Am 17.11.2011 10:04, schrieb Luca Olivetti:
Al 17/11/2011 2:15, En/na Hans-Peter Diettrich ha escrit:
Abusing strings for binary data is a bad idea.
I use strings extensively as buffers: strings in delphi/fpc {$H+} are so
convenient to use that the eventual performance hit doesn't matter to m
On 11/17/2011 02:43 AM, Hans-Peter Diettrich wrote:
The only possible (expression) optimization again is based on UTF-16,
where all sub-expressions are converted into UTF-16, so that only one
more re-conversion is required when the result is stored.
This is what mse does: using UTF-16 for the
On 11/16/2011 05:24 PM, Marco van de Voort wrote:
The original proposal was like (A) but only for base unicode encodings
(utf8/16 and maybe 32), but went down due to either excess conversions and
need for overloading. The amount of overloading for the current 3-4
stringtypes is already a bit mu
On 11/17/2011 02:15 AM, Hans-Peter Diettrich wrote:
Right, you continue to provide suggestions that only result in slow
code at runtime :-(
I did not say _anything_ about any kind of implementation, nor did I
suggest that any of the alternative "suggested variants of definitions"
is preferab
Al 17/11/2011 2:15, En/na Hans-Peter Diettrich ha escrit:
Abusing strings for binary data is a bad idea.
I use strings extensively as buffers: strings in delphi/fpc {$H+} are so
convenient to use that the eventual performance hit doesn't matter to me.
You know, I like the fact that I can sim
11 matches
Mail list logo
