On Sun, Jan 23, 2011 at 9:08 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
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.
Sorry, this was just a miscommunication, because you were talking about implementation and I was talking about interface. Once you said "refers to" all my reference-semantics bells went off. I was just trying to get you to nail down the desired semantics (i.e. no implementation details). -- Dave Abrahams BoostPro Computing http://www.boostpro.com