Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A C++ Immutable String class

blog.reliablecpp.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: A C++ Immutable String class

#51

Post by haberman »

alexchamberlain wrote: post #40
cdmh wrote: post #38

Earlier quoted context omitted.

That is accurate. The object reference by immutable msg is hello_world which is mutable. If the value of hello_world changes, then the value of msg changes too. In the simple example, it won't happen, but the point is that it could , especially when multi-threaded.

I don't buy it, by calling that function, the caller is saying the value won't change underneath you (because you are being called in multithreaded code). The object itself cannot change itself, though of course there can be mutable members, which tend to be syncronisation mechanisms (mutexes) anyway.

> I don't buy it, by calling that function, the caller is saying the value won't change underneath you

You really do not understand what "const" means in C++.

If what you said were true, a whole class of optimizations would be possible that are not currently possible. For example, consider this silly function:

  void f(const int *x) {
    int y = *x;
    g();
    if (y == *x) h();
  }
If what you said were true, this would be able to optimize away the call to h() completely, but if you compile the function with maximum optimization you will see that this is not the case. Why not? Because the caller could look like this:

  int val = 0;
  void g() { val = 1; }
  int main() { f(&val); }

Re: A C++ Immutable String class

#52

Post by zura »

zura wrote: post #8
ajuc wrote: post #7

Earlier quoted context omitted.

You specify that the place s is const, not the value it keeps. You can still do: #include #include // not your code void innocentF(std::string const& s) { (const_cast (s)) += std::string(" I'm evil."); } // your code int main() { std::string const s("hello world."); innocentF(s); std::cout

The point is that one shouldn't do it accidentally. When you're explicitly using const_cast, it is fine.

I should clarify that it is fine in a local context, when you know that originally it is a non-const variable. Otherwise, the result is undefined.

But what I meant in the above comment is that you can't accidentally type "const_cast". So when you type it, you're on your own. And there is nothing wrong with it in C++ world - if you explicitly state that you want to shoot yourself in the foot, the compiler will just listen to your orders (maybe with some warnings).

Re: A C++ Immutable String class

#53

Post by nly »

cdmh wrote: post #47
nly wrote: post #43

Earlier quoted context omitted.

libc++ (the Clang project standard C++ library) doesn't use COW for std::string, and I'm pretty sure GNU stdlibc++ will also drop it the next time they have to break ABI. C++11 move semantics and the 'small string optimisation', as it's known, blow away any performance benefit of COW for most sane uses.

COW is prohibited in C++11 Standard implementations of std::basic_string

I don't have a copy of the final 2011 standard, but as far as I can see there's nothing in the latest 2011 draft of C++11 that expressly prohibits COW.

[21.4.1.4] does say "Every object of type basic_string shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed", but that "as needed" most definitely leaves the door open for a COW implementation.

The only other part that I can see that may preclude a COW implementation is the postconditions specified for copy operations [21.4.2], which says data() returns a pointer which "points at the first element of an allocated copy of the array whose first element is pointed at by str.data()". Again though, "allocated copy" doesn't necessarily mean "a copy I just allocated". When I go and get a copy of a book I don't literally go and copy it.

In fact the standard specifies that the move constructor leave the source value "in a valid state with an unspecified value"... which again suggests you could use COW and have the source argument return the same value it had before you moved from it.

In the latest C++14 draft though (N3690), you're right, it is explicitly prohibited because "Invalidation is subtly different with reference-counted strings".

Re: A C++ Immutable String class

#54

Post by cdmh »

nly wrote: post #53
cdmh wrote: post #47

Earlier quoted context omitted.

COW is prohibited in C++11 Standard implementations of std::basic_string

I don't have a copy of the final 2011 standard, but as far as I can see there's nothing in the latest 2011 draft of C++11 that expressly prohibits COW. [21.4.1.4] does say "Every object of type basic_string shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed", but that "as needed" most definitely leaves the door open for a COW implementation. The only other par…

21.4.1 p6 states invalidation of iterators/references is only allowed for — as an argument to any standard library function taking a reference to non-const basic_string as an argument. — Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.

The non-const operator[] in a COW string requires making a copy of the string if the ref count > 1 which invalidates references and violates this paragraph.

Re: A C++ Immutable String class

#55

Post by nly »

cdmh wrote: post #54
nly wrote: post #53

Earlier quoted context omitted.

I don't have a copy of the final 2011 standard, but as far as I can see there's nothing in the latest 2011 draft of C++11 that expressly prohibits COW. [21.4.1.4] does say "Every object of type basic_string shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed", but that "as needed" most definitely leaves the door open for a COW implementation. The only other par…

21.4.1 p6 states invalidation of iterators/references is only allowed for — as an argument to any standard library function taking a reference to non-const basic_string as an argument. — Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend. The non-const operator[] in a COW string requires making a copy of the string if the ref count > 1 which invalidates references and…

Hmm true. This is what happens when you let the user violate the iterator abstraction for performance and rely on contiguity and raw refs/ptrs. It's kind of a shame, because the moment you mutating characters in a string you're often doing something silly anyway.

Re: A C++ Immutable String class

#56

Post by alexchamberlain »

to3m wrote: post #46
alexchamberlain wrote: post #40

Earlier quoted context omitted.

I don't buy it, by calling that function, the caller is saying the value won't change underneath you (because you are being called in multithreaded code). The object itself cannot change itself, though of course there can be mutable members, which tend to be syncronisation mechanisms (mutexes) anyway.

No, the caller is saying that the callee isn't permitted to change the value! That's what const means. No promise is made about the actual object itself. There's no general way to specify that in C++. This isn't so much an issue for functions, where the caller is stopped while the callee runs, but it needs to be borne in mind for longer-lived objects that take const references - or, indeed, const pointers - to object…

Ok, I know what the spec says, but it is utterly rediculous to expect people to write code in which parameters are allowed to change in an undefined way.

Re: A C++ Immutable String class

#57

Post by sesqu »

fauigerzigerk wrote: post #39

This is not an implementation I would use. One major reason for using an immutable string class instead of a const string is to get rid of the capacity member. For short strings (e.g words) the capacity member alone can be larger than the contents of the string.

A string would have to be short indeed for the capacity to be larger - something like 2 characters, I'm guessing. It's certainly a valid concern in occasional cases, but I wouldn't consider it a major reason to pass on an implementation.

Re: A C++ Immutable String class

#58

Post by fauigerzigerk »

sesqu wrote: post #57
fauigerzigerk wrote: post #39

This is not an implementation I would use. One major reason for using an immutable string class instead of a const string is to get rid of the capacity member. For short strings (e.g words) the capacity member alone can be larger than the contents of the string.

A string would have to be short indeed for the capacity to be larger - something like 2 characters, I'm guessing. It's certainly a valid concern in occasional cases, but I wouldn't consider it a major reason to pass on an implementation.

The string capacity on a 64 bit machine is usually represented as an 8 byte integer. The average length of a unique english word is 8 and the average length of a word occurrance is 5.
Post reply on HN