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
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
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
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
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
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
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 either
On Wed, Nov 16, 2011 at 5:05 PM, Sven Barth pascaldra...@googlemail.com 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
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 17 November 2011 21:51, Seth Grover sethdgrover@g 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,
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
11 matches
Mail list logo
