7 ms·

I've read the first article and I'm not convinced the problem this guy describes incurs real costs in reality. After all, there is no reason to include inline

by sltkr 14y ago

I've read the first article and I'm not convinced the problem this guy describes incurs real costs in reality. After all, there is no reason to include inline function definition in dynamic objects unless they are called without being inlined or their address is taken; both of which are extremely unlikely for class-inline methods. The author fails to convince me that if C++ didn't require taking the address of an inline functions to yield a consistent value, real-world C++ code could/would run significantly faster. The second article is pretty much obsolete with C++11, which makes copy-on-write string implementations impractical.

eridius 14y ago
How does C++11 make copy-on-write string implementations impractical? I know the short string optimization is used now, but I don't see how that's incompatible with COW (for strings that are too large to use the short string optimization). And I don't see how move constructor/assignment is incompatible either. Is there some other C++11 change that I'm overlooking?
- sltkr 14y ago
  I can't give you a definite answer, unfortunately, but I believe the more detailed specification of the semantics of string references/iterators in the new standard makes it very difficult to implement std::string with copy-on-write semantics without losing the advantages of such an implementation. For example, consider the following function: char f(string &s) { const string &t = s; const char &ch = t[1]; s[2] = 'x'; return ch; } This should be valid code, but with a copy-on-write implementation, writing to the string on line 3 could invalidate the reference created on line 2. As far as I know there isn't a proper solution to this problem without changing the return type of `std::string::operator[](size_type) const' in some non-standard way.
  - eridius 14y ago
    Did you read the 2nd link? This is a problem even in C++03. The solution is to invoke the copy on the access of `t[1]`, which is what libstdc++ does. That was the whole point of the second link; that using any operator/method that returns a char reference (operator[], at(), etc) ruins COW.
    - sltkr 14y ago
      > The solution is to invoke the copy on the access of `t[1]`, which is what libstdc++ does. No, libstdc++ specifically DOES NOT unshare the string buffer when calling the CONST version of operator[] (really, go look it up). That's the whole point of CoW: to only copy when the string is written (or at least, when you have to pessimistically assume it will be, because somebody has gotten a non-const reference to its contents). You could "fix" the issue by unsharing the buffer whenever a const iterator/reference to the string is returned, but then you lose most of the performance benefit of sharing the buffer in the first place, because most strings that are constructed are read at some point. Because of these difficulties we'll see standard library implementations move away from copy-on-write implementations and then the whole issues doesn't exist. That is to say: the performance of the test case the blog author describes will be consistently “bad” because std::string will behave pretty much like a std::deque/std::vector.

by sltkr 14y ago

eridius 14y ago

How does C++11 make copy-on-write string implementations impractical? I know the short string optimization is used now, but I don't see how that's incompatible with COW (for strings that are too large to use the short string optimization). And I don't see how move constructor/assignment is incompatible either. Is there some other C++11 change that I'm overlooking?

sltkr 14y ago
I can't give you a definite answer, unfortunately, but I believe the more detailed specification of the semantics of string references/iterators in the new standard makes it very difficult to implement std::string with copy-on-write semantics without losing the advantages of such an implementation. For example, consider the following function: char f(string &s) { const string &t = s; const char &ch = t[1]; s[2] = 'x'; return ch; } This should be valid code, but with a copy-on-write implementation, writing to the string on line 3 could invalidate the reference created on line 2. As far as I know there isn't a proper solution to this problem without changing the return type of `std::string::operator[](size_type) const' in some non-standard way.
- eridius 14y ago
  Did you read the 2nd link? This is a problem even in C++03. The solution is to invoke the copy on the access of `t[1]`, which is what libstdc++ does. That was the whole point of the second link; that using any operator/method that returns a char reference (operator[], at(), etc) ruins COW.
  - sltkr 14y ago
    > The solution is to invoke the copy on the access of `t[1]`, which is what libstdc++ does. No, libstdc++ specifically DOES NOT unshare the string buffer when calling the CONST version of operator[] (really, go look it up). That's the whole point of CoW: to only copy when the string is written (or at least, when you have to pessimistically assume it will be, because somebody has gotten a non-const reference to its contents). You could "fix" the issue by unsharing the buffer whenever a const iterator/reference to the string is returned, but then you lose most of the performance benefit of sharing the buffer in the first place, because most strings that are constructed are read at some point. Because of these difficulties we'll see standard library implementations move away from copy-on-write implementations and then the whole issues doesn't exist. That is to say: the performance of the test case the blog author describes will be consistently “bad” because std::string will behave pretty much like a std::deque/std::vector.