On Thu, 16 Mar 2006 18:05:11 -0700
L505 <[EMAIL PROTECTED]> wrote:
>
> > > > Unless you have in depth knowledge about how every bit of ansistring
> > > > memory management works, using getmem and freemem and pchars are
> > > > simpler, no? Because you are not battling the automatic memory
> > > > management. Now, if you are an expert in battling the automatic
> > > > memory management maybe you can battle ansistrings enough to be
> > > > almost or just as fast as pchars. Is this what we are doing in the
> > > > fpc sources? I will have to look, and see.
> > >
> > > Yes.
> >
> > For example: The codetools use ansistrings. Less than 1% use PChars.
> > Just avoid the + operator as you would avoid ReAllocMem and StrCopy.
>
> However, string[i] isn't so convenient as the '+' operator because you
> have to think about all your calculations quite a bit. Really string[i] is
> "smart pchars".
>
> Stringbuffer type would allow you to use the + operator and eat your cake
> too, because every time you use the + operator the getmem() is not called.
Yes, for the price of memory overhead.
> Further benefits of StringBuffer type will have to be explored - at this
> point it does'nt have enough benefits to be justified since you can just
> get along with string[i].
If there would be a capacitated string type, I would use it. Of course it
should work as a string. At least reference counted, :=, +, System.Pos,
copy, length, setlength, uniquestring.
And even nicer: the implicit uniquestring on s[]:= and the implicit
exception frames. But this requires compiler magic.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
