On Sat, Jan 22, 2011 at 3:56 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Sat, 22 Jan 2011 03:40:44 +0800, Dean Michael Berris wrote:
On Sat, Jan 22, 2011 at 3:18 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Sat, 22 Jan 2011 01:56:36 +0800, Dean Michael Berris wrote:
No changing arbitrary content in the string. Concatenation is a process of creating new strings.
But you're allowing assignment. That's not acting "as if it's const, with no way to modify the string"
Unless you frame assignment in terms of a "move".
x = "This is the original"; x = "Not anymore";
What's happening here is that you're really making x refer to a different string. In essence, x is what you might call a proxy. You can change what the proxy refers to, but what it refers to you cannot change -- if that makes any sense. If you're reading or dealing with x, basically you're dealing with the proxy.
Sorry, no, that's not value semantics. Value semantics are a subset of Stepanov's "Regular Type" concept. See EOP.
Right. So in the above, 'x' is assignable, copyable, and equality-comparable. It can enforce an ordering (total or partial) and it can be default constructed. I don't see why it doesn't support the "regular type" nor the value semantics "protocol".
Let me be clear: when you assign into x, you are modifying its value. If that can happen when x is const, x doesn't have proper value semantics. Implementation details like underlying buffers and refcounting are irrelevant.
Agreed. So it would be ill-formed to do something like this: boost::string const x("This is the initial value"); x = "Another value"; // compile error, X const doesn't have an assignment operator I didn't meant to imply that a `boost::string const` should be assignable -- I was mostly thinking about the case where it is a non-const lvalue. In which case I don't see why a proxy object wouldn't qualify for being something that follows the value semantics protocol. HTH -- Dean Michael Berris about.me/deanberris