On Wednesday 17 May 2006 20:50, Marco van de Voort wrote:
Having to check and guard each and every string operation is also not
really productive. KR tried that :-)
And I thought they did it the other way around. Leaving the check as an
exercise to the coder. ;-)
Vinzent.
Jonas Maebe wrote:
On 17 mei 2006, at 19:59, L505 wrote:
What do you guys thing about the idea to implement what DEC Pascal and
Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some* of
the path related
ShortStrings to be MediumString[1000] instead of
On 16 May 2006, at 20:32, Michael Van Canneyt wrote:
1. It's heap based. There is a lot of memory manager overhead.
2. The implicit try...finally in each procedure that uses them
introduces a memory penalty
and a speed penalty.
So I would really advise against this change. There is no
The SysUtils unit misses some performance tweaks that the Dos unit has.
Especially for the FindFirst/FindNext part. But this has low prio for the
current developpers so it hasn't been analysed and fixed yet.
What do you guys thing about the idea to implement what DEC Pascal and Extended
On 17 mei 2006, at 19:59, L505 wrote:
What do you guys thing about the idea to implement what DEC Pascal
and Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some*
of the path related
ShortStrings to be MediumString[1000] instead of ShortString[255].
For some
Jonas Maebe wrote:
On 17 mei 2006, at 19:59, L505 wrote:
What do you guys thing about the idea to implement what DEC Pascal
and Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some* of
the path related
ShortStrings to be MediumString[1000] instead of
On 17 mei 2006, at 19:59, L505 wrote:
What do you guys thing about the idea to implement what DEC Pascal
and Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some* of
the path related
ShortStrings to be MediumString[1000] instead of ShortString[255].
On 17 mei 2006, at 20:19, L505 wrote:
We wouldn't have to use sysutils yet.. we could make a custom Dos unit
which used longstrings instead of short strings, but keep the old
Dos unit for compatibility..
This still means that someone has to finish and test longstring
support in the
We wouldn't have to use sysutils yet.. we could make a custom Dos unit
which used longstrings instead of short strings, but keep the old
Dos unit for compatibility..
This still means that someone has to finish and test longstring
support in the compiler, and create this longstring Dos
Op Wed, 17 May 2006, schreef L505:
On 17 mei 2006, at 19:59, L505 wrote:
What do you guys thing about the idea to implement what DEC Pascal
and Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some* of
the path related
ShortStrings to be
I'm happy with current compiler because all I have to do is
change several of my paths to
a bit of a shorter path - it's not a big deal if you know this is
an issue that you have
to deal with. So now that the bug is known, I could live with it
for really another 10
years. The important
Well, dos.exec of course requires the entire command line as a
shortstring. This is no problem for Dos because Dos has a maximum
path length of 128
chars.
so with 2 max length paths plus some options in the command line your
screwed with shortstrings?
an issue that you have
to deal with. So now that the bug is known, I could live with it
for really another 10
years. The important part is knowing this bug so I can work
around it - if I hadn't
figured this out I would have blamed all my problems on myself.
yep silent string
Op Wed, 17 May 2006, schreef peter green:
Well, dos.exec of course requires the entire command line as a
shortstring. This is no problem for Dos because Dos has a maximum
path length of 128
chars.
so with 2 max length paths plus some options in the command line your
screwed with
Well, dos.exec of course requires the entire command line as a
shortstring. This is no problem for Dos because Dos has a maximum
path length of 128
chars.
so with 2 max length paths plus some options in the command line your
screwed with shortstrings?
Could happen, but also it might
I'm really surprised about the amount of short strings used on the FPC compiler
source,
such as short strings being used even to pass to Exec() when the linker is
called on
windows. This is obviously why for the past few years I've had all sorts of
chopped off
issues with FPC and got weird
Op Tue, 16 May 2006, schreef L505:
I'm really surprised about the amount of short strings used on the FPC
compiler source,
such as short strings being used even to pass to Exec() when the linker is
called on
windows. This is obviously why for the past few years I've had all sorts of
easier to trace!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Daniël
Mantione
Sent: 16 May 2006 17:30
To: FPC developers' list
Subject: Re: [fpc-devel] dominant short strings in compiler source
Op Tue, 16 May 2006, schreef L505:
I'm really
Op Tue, 16 May 2006, schreef peter green:
how about adding a shortstring length error option and using it when
compiling the compiler. The compiler must be doing length checking anyway to
give clean truncation so i can't imagine this would bring a signifiant
performance penalty.
This
s[0]=#255;
fillchar(s[1],255,'a');
s:=s+'a';
...will result in a string with 255 a's.
thats what it does at the moment, i don't see how this precludes adding a
compiler option to make doing this a run time error though (obviously
disabled by default for compatibility with existing code) and
On 5/16/06, L505 [EMAIL PROTECTED] wrote:
I've made some efforts to change some stuff to ansistrings to try and solve my
bug with -k
option that I mentioned recently - and although I am making progress, I realize
that I am
changing TONS of code since tons of the code uses short strings -
Are
On Tue, 16 May 2006, L505 wrote:
I'm really surprised about the amount of short strings used on the FPC
compiler source,
such as short strings being used even to pass to Exec() when the linker is
called on
windows. This is obviously why for the past few years I've had all sorts of
Op Tue, 16 May 2006, schreef Michael Van Canneyt:
On Tue, 16 May 2006, L505 wrote:
There is no problem with short strings, except for external paths.
What IS a problem is that changing it to ansistrings will significantly slow
down the compiler.
For 2 reasons:
1. It's heap based.
Op Tue, 16 May 2006, schreef peter green:
s[0]=#255;
fillchar(s[1],255,'a');
s:=s+'a';
...will result in a string with 255 a's.
thats what it does at the moment, i don't see how this precludes adding a
compiler option to make doing this a run time error though (obviously
disabled
On 16 May 2006, at 20:32, Michael Van Canneyt wrote:
1. It's heap based. There is a lot of memory manager overhead.
2. The implicit try...finally in each procedure that uses them
introduces a memory penalty
and a speed penalty.
So I would really advise against this change. There is no
Are you getting rid of shortstring in general or just short strings
that are utilized for paths?
I think it's only the shortstrings for paths that cause problems.
It was a local copy experiment of my own compiler so don't worry I'm not
committing to SVN
:-)
Well the problem I saw was that
By the way - was it ever possible in Delphi or FPC to define a very special
short string
to be of the length longer than 255, let's say
string[1000]
I remember that coming up once before on the mailing list but I forget the end
result of
the conversation.
Not that this is the answer to all our
: [fpc-devel] dominant short strings in compiler source
By the way - was it ever possible in Delphi or FPC to define a
very special short string
to be of the length longer than 255, let's say
string[1000]
I remember that coming up once before on the mailing list but I
forget the end result
well it would have to have a different in memory format. Maybe a -1 based
array with the first two locations used for length would do it.
Add new types that extend the 255 limit, using more bytes for storage to double
and even
triple our current 255 limit.
QShortString: 255 X 4 with 4 bytes
L505 wrote:
well it would have to have a different in memory format. Maybe a -1 based
array with the first two locations used for length would do it.
Add new types that extend the 255 limit, using more bytes for storage to double
and even
triple our current 255 limit.
I think once there
var
qss: QuadShortString[1020]; // why not use DoubleShortString ?
tss: TripleShortString[765];
dss: DoubleShortString[510];
ss: ShortString[255];
Vincent.
Because my math is horrible and I need to take a Computer Science course :-)
31 matches
Mail list logo
