Re: Does anyone has already seen a non mutable String based on std::string
* Luke Meyers:
Vincent RICHOMME wrote:
I am currently implementing some basic classes from .NET into modern C++.
And I would like to know if someone would know a non mutable string class.
The fact that you appear to be unaware of the fundamental C++ concept
of "const" suggests to me that you are very likely to be porting into
anything one might reasonably recognize as "modern" C++. I do not mean
to disparage -- it's just that if you're lacking basic understanding of
the language you're porting to, you're setting yourself up for failure.
Read a good C++ book or three (see the FAQ for recommendations),
*then* try something like this. The time to get to a *good* solution,
including the time taken to read the books, will still be less than if
you don't.
An immutable string class is different from 'std::string const' in that
its operations do not carry the overhead associated with mutability, and
that it supports assignment and thus can be used in standard containers.
Functionality-wise it is similar to
typedef boost::shared_ptr<std::string const> ValueString;
Consider functions foo and bah,
extern void foo( std::string& s );
void bah( std::string s ) { foo( s ); }
Can the std::string implementation avoid full deep copying of the bah
argument, that is, copying the full string value? No, it can't in
general, because function foo might change the string content: at the
very latest the string value must be copied when foo does something that
/might/ change the string content, such as applying non-const
operator[]. However, consider
extern void foo( ValueString& s );
void bah( ValueString s ) { foo( s ); }
Can the ValueString implementation avoid deep copying the bah argument?
Not only can it avoid that, but with the typedef above it does avoid that.
So -- imaginary discussion with Luke ;-) -- why not then just write
void bah( std::string const& s ) { ... // Uh...
Yes, if you do that then you can't call function foo without first
making your own deep copy.
One problem with ValueString as defined above is that it has two levels
of dynamic memory management and allocation. Presumably a native
implementation of ValueString could manage with just one level,
dynamically allocating its internal buffer. Thus, more efficient.
There is also efficiency concerns with respect to thread safety. But my
mind is a little foggy right now. At least, the example generator is
completely silent, not coming up with any examples (I guess a bit of
Googling for string and thread safety and copy-on-write would be the thing).
So, it appears to me that Vincent is well aware of the C++ aspect.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?