On 18 May 06, at 13:50, L505 wrote:
.
.
have tight custom units with no end user units like sysutils. One way to
accomplish this,
like I've already mentioned, is to use shortstring/longstring/array of
string/ based Dos
unit, using shortstrings where necessary, arrays of strings where
Forgive me if I'm saying BS but it's been about 10 years since I
programmed in TurboPascal (and used ShortStrings), but don't
ShortStrings use the size they are declared with? And 255 is just
default size (if no size is specified)?
The shortstring type does, but you can use a pointer to a
Also, using some compiler trickery can be done to optimize usage of
AnsiStrings so we can avoid use of PChars, but of course this will
have to wait a bit.
Or programmer trickery - the fpc souce already contains lots of programmer
trickery around
ansistrings such as using uniquestring,
.
.
have tight custom units with no end user units like sysutils. One way to
accomplish
this,
like I've already mentioned, is to use shortstring/longstring/array of
string/ based
Dos
unit, using shortstrings where necessary, arrays of strings where
necessary, and
arrays of
On 20 May 06, at 11:43, L505 wrote:
.
.
have tight custom units with no end user units like sysutils. One way to
accomplish
this,
like I've already mentioned, is to use shortstring/longstring/array of
string/ based
Dos
unit, using shortstrings where necessary, arrays of
On Sat, 20 May 2006, Tomas Hajny wrote:
Regarding unit Dos - providing PChar versions of
some routines might be of general use, probably
more useful than longstrings.
Admitting that C-language style programming (*char) is more practical and
real world than
Pascal programming?
On 20 May 06, at 11:43, L505 wrote:
more useful than longstrings.
Admitting that C-language style programming (*char) is more practical and
real world than
Pascal programming?
;-) Well, that depends. I certainly don't think
that *char is more practical for string
manipulation
On 20 May 2006, at 22:39, Marco van de Voort wrote:
- Can turning implict excepctions off in core parts improve ansistring
performance?
Implicit exceptions are already turned of for the entire compiler.
Jonas
___
fpc-devel maillist -
IMHO this whole discussion is nonsense. For basic path related stuff,
ansistring is good enough, and if findfirst/findnext are still limiting with
the current memmgr (afaik we changed to Micha's one since those original
tests).
Moreover, if the weak point of ansistrings is the heap copying
writeln('Let''s combine a short string with a wordstring.. (press enter)');
readln;
sstring:= ', interesting world.';
WordStrConcat(sstring, wordstr1); // no memory allocated
sorry, forgot to include the actual shortstring overloaded function - my copy
and paste
skills are getting
Op Thu, 18 May 2006, schreef Flávio Etrusco:
L Dynamic arrays can be very handy and I never knew anyone who avoids
L them. Of course if your array has fixed length there's no reason
L to use a dynamic array either.
L Fortunately it's no very often that one falls in Borland's trap
L
Sorry, these two letters were accidentally sent personally.
To Felipe Monteiro de Carvalho:
probably Windows will become totally utf16 (not really unicode, but
at least utf16) really soon (at least in newer versions in a way
incompatible with current ones).
A small correction, utf16 is
Also assembler symbols/labels should get extended to strings 255 in the
future because there is already a bug open in which it is demonstrated
that it is possible to create too long labels which makes a program
uncompilable.
Or some scheme derived which makes sure that labels never get
On Fri, 19 May 2006 18:29:29 +0100
Peter Vreman [EMAIL PROTECTED] wrote:
There are already some complains about the memory usage. Increasing the
string size adds a lot more overhead. Especially for all the small labels
like .L1 etc. Already using longstrings will add 3 bytes for the length
Op Fri, 19 May 2006, schreef Micha Nelissen:
On Fri, 19 May 2006 18:29:29 +0100
Peter Vreman [EMAIL PROTECTED] wrote:
There are already some complains about the memory usage. Increasing the
string size adds a lot more overhead. Especially for all the small labels
like .L1 etc.
On 5/19/06, Daniël Mantione [EMAIL PROTECTED] wrote:
Op Fri, 19 May 2006, schreef Micha Nelissen:
On Fri, 19 May 2006 18:29:29 +0100
Peter Vreman [EMAIL PROTECTED] wrote:
There are already some complains about the memory usage. Increasing the
string size adds a lot more overhead.
On 5/19/06, Daniël Mantione [EMAIL PROTECTED] wrote:
Op Thu, 18 May 2006, schreef Flávio Etrusco:
L Dynamic arrays can be very handy and I never knew anyone who avoids
L them. Of course if your array has fixed length there's no reason
L to use a dynamic array either.
L Fortunately
Op Fri, 19 May 2006, schreef Flávio Etrusco:
Free Pascal is Delphi compatible.
I know that FPC aims to be Delphi-compatible, but it's not always the
case, as e.g. the WideStrings were reference-counted until a couple of
months ago.
So you are saying that in this is specific case FPC is
Op Fri, 19 May 2006, schreef Flávio Etrusco:
Forgive me if I'm saying BS but it's been about 10 years since I
programmed in TurboPascal (and used ShortStrings), but don't
ShortStrings use the size they are declared with? And 255 is just
default size (if no size is specified)?
Of course.
On 5/19/06, Пётр Косаревский [EMAIL PROTECTED] wrote:
Sorry, these two letters were accidentally sent personally.
To Felipe Monteiro de Carvalho:
probably Windows will become totally utf16 (not really unicode, but
at least utf16) really soon (at least in newer versions in a way
Hello,
From: Jonas Maebe [EMAIL PROTECTED]
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
Op Thu, 18 May 2006, schreef Thomas Schatzl:
Also assembler symbols/labels should get extended to strings 255 in the
future because there is already a bug open in which it is demonstrated that it
is possible to create too long labels which makes a program uncompilable.
Or some scheme
L Can someone tell me how slow/fast a dynamic array is compared to a fixed
one? Say you used
L a dynamic array of chars or dynamic array of shortstrings - would the
dynamic array be
L slow on a general basis? Maybe we will have to resort to benchmarks using
the cpu timer.
L And then there is
But it's only a matter of time:
probably Windows will become totally utf16 (not really unicode, but
at least utf16) really soon (at least in newer versions in a way
incompatible with current ones).
A small correction, utf16 is a type of unicode.
thanks,
--
Felipe Monteiro de Carvalho
On 5/18/06, Пётр Косаревский с mail.ru [EMAIL PROTECTED] wrote:
L Can someone tell me how slow/fast a dynamic array is compared to a fixed
one? Say you used
L a dynamic array of chars or dynamic array of shortstrings - would the
dynamic array be
L slow on a general basis? Maybe we will have to
25 matches
Mail list logo
