Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

> It appears that we have come almost full circle here.  You would tell
> such an implementor what I assumed you were trying to tell me in your
> first response: the description of the function specifies only its
> required effect, not the way it must be implemented, only in this case
> the wording gets the effect right, as far as I can see, in contrast
> with the wording in the version submitted for public comment.

Your version and the draft's differ only in their side-effects - but as I
read it, in the "returns" section the side-effects, if any, are
irrelevant.  A scrap of "equivalent" code that describes the return value
is not, I believe, to be read as describing anything BUT the return value,
and hence it makes no difference in principle whether those side effects
are "correct" or not.  They just don't matter, and if you act as though
they do you the code will appear to over-describe (and constrain) the
implemnetation - that was the point of the hypothetical question someone
might make of the version you posted.

The long-winded version I posted was an attempt to avoid the potential
for confusion and over-specification that is inherent in using C++ to
describe a C++ function's semantics.

Martin Maney (maney@MCS.COM) wrote:
: Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

: > The draft for the Strings library has an odd description of operator+
: > in section 21.1.1.10.1, where it says:

: >  template<class charT, class traits, class Allocator>
: >    basic_string<charT,traits,Allocator>
: >      operator+(const basic_string<charT,traits,Allocator>& lhs,
: >         const basic_string<charT,traits,Allocator>& rhs);
: >  Returns lhs.append(rhs).

: > If you look back as 21.1.1.8.2, basic_string::append, you see that
: > basic_string::append() is a non-const member function, which means
: > that it can't be used to implement operator+(), for which lhs is
: > a const object.  It wouldn't make sense anyway, because that would
: > duplicate the functionality of basic_string::operator+= (see
: > 21.1.1.8.1).  Don't we want operator+ to create an entirely new
: > object, not just append to lhs?

: Of course.  I think the problem is that you're reading an abstract
: description of the result of operator+ as if it were intended to be a
: prescription for the implementation.  I suppose this could be stated more
: explicitly.

I understand what you're driving at, but even in the more limited
context of trying to describe solely the effect of the operator (as
opposed to how this effect is accomplished) this specification is
flawed.  The *effect* of lhs.append(rhs) is modification of lhs,
and further, this effect does *not* include creation of a new object.
If the programmer must accept this description of the result of
operator+, (s)he would have to assume that the return value is no
longer usable after the lifetime of lhs comes to an end.  (S)he would
also have to assume that modifications to the returned object will be
reflected in lhs.

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

> The draft for the Strings library has an odd description of operator+
> in section 21.1.1.10.1, where it says:

>  template<class charT, class traits, class Allocator>
>    basic_string<charT,traits,Allocator>
>      operator+(const basic_string<charT,traits,Allocator>& lhs,
>         const basic_string<charT,traits,Allocator>& rhs);
>  Returns lhs.append(rhs).

> If you look back as 21.1.1.8.2, basic_string::append, you see that
> basic_string::append() is a non-const member function, which means
> that it can't be used to implement operator+(), for which lhs is
> a const object.  It wouldn't make sense anyway, because that would
> duplicate the functionality of basic_string::operator+= (see
> 21.1.1.8.1).  Don't we want operator+ to create an entirely new
> object, not just append to lhs?

Of course.  I think the problem is that you're reading an abstract
description of the result of operator+ as if it were intended to be a
prescription for the implementation.  I suppose this could be stated more
explicitly.

Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

> Martin Maney (maney@MCS.COM) wrote:
> : Of course.  I think the problem is that you're reading an abstract
> : description of the result of operator+ as if it were intended to be a
> : prescription for the implementation.  I suppose this could be stated more
> : explicitly.

> I understand what you're driving at, but even in the more limited
> context of trying to describe solely the effect of the operator (as
> opposed to how this effect is accomplished) this specification is
> flawed.  The *effect* of lhs.append(rhs) is modification of lhs,
> and further, this effect does *not* include creation of a new object.

I understand your objection, and agree that the wording can be improved.
I believe that you are bending over backwards to misinterpet it, however:
to me, talking about the "effect" of operator+ sounds very like you're
still thinking about the implementation.  Let me see if I can write that
without implicitly assuming anything:

  Returns a new basic_string<...> whose contents is the same as that
  which would be created by lhs.append(rhs).

I suppose that the standard may actually need to be this verbose (and I'm
not sure that "contents is the same as" is really adequate to prevent
misinterpretation).  Oh well, another hundred pages more or less...

Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

> What's wrong with "Returns string(lhs).append(rhs)"?

I was trying to avoid giving something that looked like an
implementation, since that muddies the issue.  Given your suggestion, I
expect someone will ask "we wanted to optimize operator+ by using a
private constructor that builds the concatenated string in one step
rather than copying lhs and appending rhs, but the standard says..."

Perhaps I'm just overly sensitized to this sort of thing right now.  ;-)

According to Martin Maney <maney@MCS.COM>:
> Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:
>
> > What's wrong with "Returns string(lhs).append(rhs)"?
>
> I was trying to avoid giving something that looked like an
> implementation, since that muddies the issue.  Given your suggestion, I
> expect someone will ask "we wanted to optimize operator+ by using a
> private constructor that builds the concatenated string in one step
> rather than copying lhs and appending rhs, but the standard says..."

The standard is filled with "As if..." ' s.  I'm sure something
similar would be appropriate here.  (In fact, IMHO there is an
implied "As if" to almost everything in the standard.)


Pete

Martin Maney (maney@MCS.COM) wrote:

: I understand your objection, and agree that the wording can be improved.
: I believe that you are bending over backwards to misinterpet it, however:
: to me, talking about the "effect" of operator+ sounds very like you're
: still thinking about the implementation.  Let me see if I can write that
: without implicitly assuming anything:

:   Returns a new basic_string<...> whose contents is the same as that
:   which would be created by lhs.append(rhs).

: I suppose that the standard may actually need to be this verbose (and I'm
: not sure that "contents is the same as" is really adequate to prevent
: misinterpretation).  Oh well, another hundred pages more or less...

What's wrong with "Returns string(lhs).append(rhs)"?

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

Martin Maney (maney@MCS.COM) wrote:
: Bob Kline Phoenix Contract (bkline@cortex.nlm.nih.gov) wrote:

: > What's wrong with "Returns string(lhs).append(rhs)"?

: I was trying to avoid giving something that looked like an
: implementation, since that muddies the issue.  Given your suggestion, I
: expect someone will ask "we wanted to optimize operator+ by using a
: private constructor that builds the concatenated string in one step
: rather than copying lhs and appending rhs, but the standard says..."

: Perhaps I'm just overly sensitized to this sort of thing right now.  ;-)

It appears that we have come almost full circle here.  You would tell
such an implementor what I assumed you were trying to tell me in your
first response: the description of the function specifies only its
required effect, not the way it must be implemented, only in this case
the wording gets the effect right, as far as I can see, in contrast
with the wording in the version submitted for public comment.

This is the library section's version of the "as if" rule which applies
to the entire document.  In fact, there is language in [lib.structure.
requirements] which says so explicitly:

17.2.1.2, paragraph 5 -- "In some cases the semantic requirements are
presented as C++ code.  Such code is intended as a specification of
equivalence of a construct to another construct, not necessarily as
the way the construct must be implemented."

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

This is a repost of a question submitted to this newsgroup some time
back.  I never received any responses, and am resubmitting it in
the hope that someone will find time in between responding to the
more colorful but off-topic posts to show me what I'm missing here.
:->}

The draft for the Strings library has an odd description of operator+
in section 21.1.1.10.1, where it says:

 template<class charT, class traits, class Allocator>
   basic_string<charT,traits,Allocator>
     operator+(const basic_string<charT,traits,Allocator>& lhs,
        const basic_string<charT,traits,Allocator>& rhs);
 Returns lhs.append(rhs).

If you look back as 21.1.1.8.2, basic_string::append, you see that
basic_string::append() is a non-const member function, which means
that it can't be used to implement operator+(), for which lhs is
a const object.  It wouldn't make sense anyway, because that would
duplicate the functionality of basic_string::operator+= (see
21.1.1.8.1).  Don't we want operator+ to create an entirely new
object, not just append to lhs?

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/