[boost] Re: immutable string

From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2004-09-18 19:27:23

David B. Held <dheld_at_[hidden]> wrote:

>> I've been working on a small library - an immutable C++ string. Now it  
>> is  in usable state and has been put in use in a couple of real  
>> projects.  Although it needs further polishing, I would like to know is  
>> there any  interest in such a library?
>>  Here is the link: http://conststring.sourceforge.net/
>
> First, I'll say that yes, I am very interested in a library such as
> this.  Second, let me say that "const_string<>" and "immutable string"
> don't seem like the right terms to me.  The fact that you can call
> operator?=() and append() on it tell me that there is little that is
> "const" or "immutable" about it.  It seems to me that "cow_string<>"
> would be more appropriate, but perhaps others have different opinions.

Well, I just did not have a better idea and called it so. If there is a  
more suitable name I will happily rename it.

> Without taking a super-deep look at the code, I will say that it looks
> fairly clean and appears to appropriately use modern techniques.  A
> small detail is that I would tend to call const_string_storage a policy,
> since that is basically how it is being used.

I agree that the const_string_storage is indeed a policy. I did not call  
it policy because I felt it was very unlikely a user would ever want to  
implement it herself, since the class essentially provides the core  
interface and functionality that makes the string constant. I would rather  
go for named template parameters technique to hide const_string_storage  
 from the user, and it was not done so because I am still not sure about  
this.

> You could call it a
> StoragePolicy for the string.  Also, types ending in _t tend to be
> reserved for typedefs of fundamental types.  By convention, we usually
> name template parameters with Capitalized names.  charT, Allocator,
> StoragePolicy, etc.

I partially agree. Using something to distinguish type names from variable  
names is often beneficial and I think a suffix is much better than a  
prefix. I knew about boost conventions and yet I've been seeing libraries  
in boost that do not follow it. Anyway, this is not an issue for me and  
can be easily changed.

> I suppose its not completely a COW string, since you don't support the
> full set of mutating operations.

The intent is exactly not to provide mutating operations that change  
individual characters of the string. The string object itself can be  
actually changed (just like you can't change the string pointed by char  
const* p, but you can change p to point to another string).

> However, some more documentation would
> be nice.  In particular, I would like to see guarantees about size and
> performance as compared to basic_string<>, etc.

Yes, that what I'm thinking about right now.

I have very little free time these days to carefully write docs. The text  
at the link was written from scratch during a free hour I had today to get  
some feedback from you guys.

Thank you Dave and all others for the interest and the precious time spent  
into looking at the stuff. After reading your posts I see that I should  
elaborate the docs in the first place and then polish it...

-- 
Maxim Yegorushkin