Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-24 06:32:14

On Sun, Jan 23, 2011 at 9:08 PM, Dean Michael Berris
<mikhailberis_at_[hidden]> 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