On 6/28/2019 3:07 PM, Ryan Joseph wrote:
On Jun 28, 2019, at 3:40 PM, Martok wrote:
So, I would expect (and FastMM has codepaths for that), that repeated
reallocations cause some form of "over-allocating" growth and most of the
individual "+1" reallocs will be essentially no-ops.
Interesting.
> On Jun 28, 2019, at 3:40 PM, Martok wrote:
>
> So, I would expect (and FastMM has codepaths for that), that repeated
> reallocations cause some form of "over-allocating" growth and most of the
> individual "+1" reallocs will be essentially no-ops.
Interesting. How could we test this to see
> Yes indeed. FPC already has an overwhelming amount of string types. As I said
> though a SetCapacity option for growing would be nice (for dynamic arrays
> also) because += is such a common operation. As it stands I often don’t use
> dynamic arrays (and now ansistring) because of growing
Am 27.06.2019 um 07:10 schrieb Sven Barth:
Am 26.06.2019 um 23:36 schrieb Ryan Joseph:
On Jun 26, 2019, at 3:28 PM, Ben Grasset wrote:
I think Ryan probably meant his own custom types. And certainly, you
can do some interesting stuff with operator overloading that mostly
avoids the normal
Am 26.06.2019 um 23:36 schrieb Ryan Joseph:
On Jun 26, 2019, at 3:28 PM, Ben Grasset wrote:
I think Ryan probably meant his own custom types. And certainly, you can do
some interesting stuff with operator overloading that mostly avoids the normal
AnsiString overhead. Here's an example.
On Wed, Jun 26, 2019 at 5:36 PM Ryan Joseph wrote:
> Yes indeed. FPC already has an overwhelming amount of string types. As I
> said though a SetCapacity option for growing would be nice (for dynamic
> arrays also) because += is such a common operation. As it stands I often
> don’t use dynamic
> On Jun 26, 2019, at 3:28 PM, Ben Grasset wrote:
>
> I think Ryan probably meant his own custom types. And certainly, you can do
> some interesting stuff with operator overloading that mostly avoids the
> normal AnsiString overhead. Here's an example.
Yes indeed. FPC already has an
On Wed, Jun 26, 2019 at 3:28 PM Ben Grasset wrote:
> I think Ryan probably meant his own custom types. And certainly, you can
> do some interesting stuff with operator overloading that mostly avoids the
> normal AnsiString overhead. Here's an example.
>
On Wed, Jun 26, 2019 at 5:48 AM Michael Van Canneyt
wrote:
> I second that.
>
> Michael.
>
I think Ryan probably meant his own custom types. And certainly, you can do
some interesting stuff with operator overloading that mostly avoids the
normal AnsiString overhead. Here's an example.
On Wed, 26 Jun 2019, Marco van de Voort wrote:
Op 25/06/2019 om 21:58 schreef Ryan Joseph:
An exponential growing function applied to all strings would have many
worse case behaviours, where it would eat up heaps of memory for nothing.
This is why it is better to have the programmer
Op 25/06/2019 om 21:58 schreef Ryan Joseph:
An exponential growing function applied to all strings would have many worse
case behaviours, where it would eat up heaps of memory for nothing. This is why
it is better to have the programmer indicate it is a growing string some how
(or have a
> On Jun 25, 2019, at 3:55 PM, Marco van de Voort
> wrote:
>
> An exponential growing function applied to all strings would have many worse
> case behaviours, where it would eat up heaps of memory for nothing. This is
> why it is better to have the programmer indicate it is a growing string
Op 2019-06-25 om 21:12 schreef Ryan Joseph:
On Jun 25, 2019, at 2:16 PM, Jonas Maebe wrote:
It has to allocate a new ansistring.
Another question: if I do "s += c” will the string reallocate memory for 1
character or is there an exponential growing function? If it does grow by one
On 25/06/2019 21:12, Ryan Joseph wrote:
>
> Another question: if I do "s += c” will the string reallocate memory for 1
> character or is there an exponential growing function? If it does grow by one
> character at a time how can I reserve a certain capacity in advance?
Strings always contain
> On Jun 25, 2019, at 2:16 PM, Jonas Maebe wrote:
>
> It has to allocate a new ansistring.
Another question: if I do "s += c” will the string reallocate memory for 1
character or is there an exponential growing function? If it does grow by one
character at a time how can I reserve a certain
> On Jun 25, 2019, at 2:16 PM, Jonas Maebe wrote:
>
> On 25/06/2019 20:15, Ryan Joseph wrote:
>> I’m making some string helper functions and using ansistring as inputs (in
>> case there are longer strings than 255 chars). What happens when you pass a
>> short string as an ansistring? Does
On 25/06/2019 20:15, Ryan Joseph wrote:
> I’m making some string helper functions and using ansistring as inputs (in
> case there are longer strings than 255 chars). What happens when you pass a
> short string as an ansistring? Does the compiler have to allocate a new
> ansistring or can it do
I’m making some string helper functions and using ansistring as inputs (in case
there are longer strings than 255 chars). What happens when you pass a short
string as an ansistring? Does the compiler have to allocate a new ansistring or
can it do some smart optimization?
Regards,
Ryan
18 matches
Mail list logo
