Re: Ann: Natools.Chunked_Strings, beta 1

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2011-11-30, Yannick Duchêne <yannick_duchene@yahoo.fr> wrote:
> Le Tue, 29 Nov 2011 16:37:27 +0100, Pascal Obry <pascal@obry.net> a écrit:
>> Do you have some speed/memory comparison between your Chunked_String and
>> GNAT Unbounded_String?
> Probably not relevant as a generality: depends on string lengths.

Of course, that's why the x-axis of a benchmark graph has to be string
length.

> By the way, I feel the original message is based on erroneous assumptions  
> about implementations of Ada.Strings.Unbounded. Nothing in the RM requires  
> an implementations to use a single array for unbounded strings, and on the  
> opposite, it says `type Unbounded_String is private;`.

That is not true. The only assumption was that in the specific case of
building a somewhat large string through repeated append, an
implementation optimized for that use case would perform better than
Ada.Strings.Unbounded, which is presumably all-purpose. Hence
String_Accumulator interface.

Then it is a fact that GNAT implementation of Ada.Strings.Unbounded is a
single contiguous array that is dynamically resized, and each resize
costs a full copy of the contents (i.e. there is equivalent to C's
realloc() that may resize an array without copy.

Combined with the fact I use GNAT is enough (for me) to justify writing
Natools.Chunked_Strings.

> At least for that reason, I feel this would be even better to stick to the  
> exact same interface as the one of Ada.Strings.Unbounded. If that's  
> another implementation of Ada.Strings.Unbounded, then, this should expose  
> the same interface. This way, the client side could easily use one or the  
> other via static polymorphism.

And what exactly is preventing the client side from doing exactly that?
That's what I did in the client packages, through changes similar of
what was described about GNAT.Spitbol.


Natasha