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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk