> 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
> 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 copy
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 - fpc-devel
> 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
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
> > Pas
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 ne
> .
> .
> > 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
ar
> 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
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
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, 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 overh
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
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 leng
> That's one solution, that's not the only solution.
Very right. It is a trade-off. Do you fix the shortstring issue
and continue to get their benefits, or do you abandon them,
rewrite large parts of the compiler and pay the performance/memory
usage price?
There are already some complains abo
I think you guys may be living in a 255 cave, simply because that's all we
have to deal
with at this time. Some say that ansistrings might be the way to go using
sysutils -
personally I think sysutils has no place in the compiler core and the
compiler core should
have tight custom units with
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 lar
Op Thu, 18 May 2006, schreef L505:
> That's one solution, that's not the only solution.
Very right. It is a trade-off. Do you fix the shortstring issue
and continue to get their benefits, or do you abandon them,
rewrite large parts of the compiler and pay the performance/memory
usage price?
> > 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
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 d
19 matches
Mail list logo
