RE: [boost] String thought

From: Matthew Hurd (matt_at_[hidden])
Date: 2003-11-08 08:03:14

> On Behalf Of Pavol Droba
> Sent: Saturday, 8 November 2003 11:21 PM
> To: Boost mailing list
> Subject: Re: [boost] String thought
> 
> On Sat, Nov 08, 2003 at 01:28:05PM +1100, Matthew Hurd wrote:
> 
> [snip]
> 
> > Convenience and speed for the user versus a more complicated library...
> >
> > I can't see how to inject this into std to make it practical for a
> user...
> > it would have to be the library writer.  Is that true?  Beyond me...
> >
> 
> In my opinion, the benefits are not worth the extra complication in this
> case.
> I cannot realy imagine much more that could be optimized in addtion to
> string concatenation.

Yep, neither can I, but string concatenation can be pretty common.
 
> In in this case there is an easy way for optimization, when it is required
> (using +=).

With judicious use of 'reserve' I'd think too, which complicates matters a
little.  Otherwise you are still, potentially, reallocing depending on the
size sizes and underlying implementation memory management.

This is why there is still a small 15% benefit to the expression template
over the a = b; a += c.... code sequence in my previous numbers.  This is
why I'd guess smart use of reserve by the programmer, should eliminate that
though and make them equal. 

Though it is kind of annoying to have to think about it from a user's
perspective when it could just be efficient anyway :-)

> So if the performance does matter, user has a simple solution.
> If the performance is not important, there is not need for complication,
> that such
> a framework would bring.

Pretty much, though the user really wouldn't have to worry about this if
    a = b + c +...
was an expression template

I think I agree that it is best left to the std::string library writers
(outside Boost's scope) so that it is completely transparent to the user
which is what I'm twisting your words to mean :-)

At least it was fun to come up with something faster than current MSVC and
GCC std library implementations.  I hope they adopt the approach.

Another one for Andrei's YASL perhaps ;-)

> Just my $0.03
> 
> Regards,
> 
> Pavol

Thanks for the feedback.

Cheers,

Matt Hurd.