Does anyone has already seen a non mutable String based on std::string

V

Vincent RICHOMME

Hi,

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.
 
T

Tomás

Vincent RICHOMME posted:
Hi,

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.


Never heard the term, "non-mutable class", before.


What's a non-mutable class? Is it a class which has no member objects which
are mutable?


-Tomás
 
V

Vincent RICHOMME

Tomás a écrit :
Vincent RICHOMME posted:



Never heard the term, "non-mutable class", before.


What's a non-mutable class? Is it a class which has no member objects which
are mutable?


-Tomás
non mutable means that once created object cannot be modidified.
In the case of string, it means that once the string has been allocated
it cannot be modified or if you want to modify it, the modification is
done on a copy and not on the string itself.
Actually I have found one implementation on sourceforge and based on
boost but I don't like boost dependencies.
 
T

Tomás

Vincent RICHOMME posted:

non mutable means that once created object cannot be modidified.

#include <string>

int main()
{
std::string const str("Etched in stone.");
}


Am I missing something?


-Tomás
 
R

Roland Pibinger

Tomás a écrit :
non mutable means that once created object cannot be modidified.
In the case of string, it means that once the string has been allocated
it cannot be modified or if you want to modify it, the modification is
done on a copy and not on the string itself.

Actually, you cannot translate an immutable Java or C# String class to
C++ without difficulties. A C++ string class is supposed to be a value
object (otherwise you would create yet another "smart" pointer)
whereas (immutable) strings in Java/C# are reference objects. In C++ a
truly immutable value object e.g. could not be copied into a
std::container.
Actually I have found one implementation on sourceforge and based on
boost but I don't like boost dependencies.

http://www.codeproject.com/string/fix_str.asp

I already have a newer version but since there is not much interest I
will not update article and code in the near future.

Best wishes,
Roland Pibinger
 
T

Tomás

Alex Buell posted:
D'you mean const std::string str("So's this") is different to that?


Haven't a clue why you suggested that. . . ?


The following two definitions are EXACTLY equivalent:

std::string const str;

const std::string str;


C++ just gives a bit of poetic license as to how you want to write it.


-Tomás
 
L

Luke Meyers

Vincent said:
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.

Luke
 
K

kwikius

Roland said:
Actually, you cannot translate an immutable Java or C# String class to
C++ without difficulties. A C++ string class is supposed to be a value
object (otherwise you would create yet another "smart" pointer)
whereas (immutable) strings in Java/C# are reference objects. In C++ a
truly immutable value object e.g. could not be copied into a
std::container.


http://www.codeproject.com/string/fix_str.asp

I already have a newer version but since there is not much interest I
will not update article and code in the near future.

You might want to look at The most popular downloads in the Boost
Vault, where fixed_string was most popular download:

http://tinyurl.com/rstoa

Note that the version there was reviewed but not accepted:

http://www.boost.org/more/formal_review_schedule.html

The reasons were IIRC that the implementation had moved away from the
expected concept of a fixed string and so wasnt what potential users
were looking for. However the large amount of downloads suggests that
there is a lot of interest in this functionality. I havent looked at
your version in detail but from looking at the intro, it looks like it
might be worth posting a link to it on the boost developers list to see
whether there is interest. I think there might be.

regards
Andy Little
 
A

Alf P. Steinbach

* Luke Meyers:
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.
 
R

Roland Pibinger

On 28 May 2006 10:57:50 -0700, "kwikius" >You might want to look at
The most popular downloads in the Boost
Vault, where fixed_string was most popular download:

http://tinyurl.com/rstoa

Note that the version there was reviewed but not accepted:

http://www.boost.org/more/formal_review_schedule.html

Grande confusione! boost::fixed_string is not an immutable string
The reasons were IIRC that the implementation had moved away from the
expected concept of a fixed string and so wasnt what potential users
were looking for. However the large amount of downloads suggests that
there is a lot of interest in this functionality. I havent looked at
your version in detail but from looking at the intro, it looks like it
might be worth posting a link to it on the boost developers list to see
whether there is interest. I think there might be.

Thank you for considering my code 'boost-able' but my goal was exactly
the opposite. 'fix_str' consists of very lightweight classes (not
templates, no traits and policies involved) with specified performance
characteristics for copying, assignment and default construction
(unlike std::string).

Best regards,
Roland Pibinger
 
R

Roland Pibinger

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;

Actually, that should be avoided! Immutable objects make only sense as
immutable value objects. In C++ (not in Java) 'value object' means
that an assignment replaces (=mutates) the original object, not just a
reference to it. A totally immutable value object would not be very
useful in C++ (e.g. you could not assign a return value). I asked some
time ago for a name for 'assignable-but-otherwise-immutable-objects'.
The concept seems to be known but there is no established name for it.

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/b1ef8b7634c0dc7

Best regards,
Roland Pibinger
 
K

kwikius

Roland said:
Thank you for considering my code 'boost-able' but my goal was exactly
the opposite.

The opposite of boost-able... ? Would that be unboost-able. Is this a
deliberate aim? :)
'fix_str' consists of very lightweight classes (not
templates, no traits and policies involved) with specified performance
characteristics for copying, assignment and default construction
(unlike std::string).

AFAIK http://www.boost.org has no requirement that a candidate library
uses templates, traits or policies.

regrads
Andy Little
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,189
Latest member
CryptoTaxSoftware

Latest Threads

Top