Re: [boost] Interest in super string class?

From: David Abrahams (dave_at_[hidden])
Date: 2006-07-03 08:39:02

Marc Mutz <marc_at_[hidden]> writes:

> On Monday 03 July 2006 00:14, Jeff Garland wrote:

>> I assume you meant

>>

>>    s = s.trim();

>

> After renaming trim_copy(), yes. Otherwise no.

>

>> Well, that's very persuasive although I think it's harder to write

>> something modifies a collection of objects in place -- no?

>

> Very good point. With a mutating trim(), people are tempted to write

>   std::for_each( v.begin(), v.end(), mem_fn( &super_string::trim ) );

> which, strictly speaking, is not explicitly allowed by the std, IIRC. With a 

> const trimmed(), the user would be forced to use

>   std:transform(v.begin(),v.end(),v.begin(),mem_fn(&super_string::trimmed));

> which much better conveys what the code does.

>

>> Don't get me 

>> wrong, I'm pretty fond of immutable value types.  Most of date_time is

>> written as immutable value types with a couple exceptions.  However, in

>> this case I'm building on a base type that's already mutable and it seems

>> to me that it's pretty natural to say s.replace_all(...).

>

> It's only natural b/c it's what people are used to. It's much easier, IMHO, to 

> work with immutable types, 

In general, yes, and I would oppose the acceptance of a new C++ string

class into Boost if it weren't immutable.  And once you know it's

immutable, you don't need naming contortions like "trim_copy."  "trim"

will do nicely.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com