On Jul 12, 1:07 am, Joe Gottman <jgott...@carolina.rr.com> wrote:
> The latest draft of the working paper for C++09 has the following spec
> for the version of basic_string::operator+() that takes two rvalue
> references:
>
>      template<class charT, class traits, class Allocator>&&
>        basic_string<charT,traits,Allocator>
>          operator+(basic_string<charT,traits,Allocator>&& lhs,
>                    basic_string<charT,traits,Allocator>&& rhs);
>
> -4- Returns: lhs.append(rhs). [Note: or equivalently rhs.insert(0, lhs)
> --end note]
>
>     There's a slight problem with the returns clause and the
> accompanying note: lhs.append(rhs) and rhs.insert(0, lhs) are not really
> equivalent. If lhs has a large enough capacity() to hold the sum of the
> two strings without reallocation and rhs doesn't then returning
> lhs.append(rhs) is much more efficient than returning rhs.insert(0,
> lhs).  On the other hand, if rhs has a large enough capacity() and lhs
> doesn't then the opposite is true.  Since the entire reason for defining
> this overload is to avoid reallocation, shouldn't the returns clause
> specify that we chose an option that doesn't reallocate if one exists?

Isn't that a quality-of-implementation issue?

The Returns clause specifies semantics, and the semantics seems
correct.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1184255371.768277.318110@n60g2000hse.googlegroups.com>,
 Pedro Lamarao <pedro.lamarao@gmail.com> wrote:

> On Jul 12, 1:07 am, Joe Gottman <jgott...@carolina.rr.com> wrote:
> > The latest draft of the working paper for C++09 has the following spec
> > for the version of basic_string::operator+() that takes two rvalue
> > references:
> >
> >      template<class charT, class traits, class Allocator>&&
> >        basic_string<charT,traits,Allocator>
> >          operator+(basic_string<charT,traits,Allocator>&& lhs,
> >                    basic_string<charT,traits,Allocator>&& rhs);
> >
> > -4- Returns: lhs.append(rhs). [Note: or equivalently rhs.insert(0, lhs)
> > --end note]
> >
> >     There's a slight problem with the returns clause and the
> > accompanying note: lhs.append(rhs) and rhs.insert(0, lhs) are not really
> > equivalent. If lhs has a large enough capacity() to hold the sum of the
> > two strings without reallocation and rhs doesn't then returning
> > lhs.append(rhs) is much more efficient than returning rhs.insert(0,
> > lhs).  On the other hand, if rhs has a large enough capacity() and lhs
> > doesn't then the opposite is true.  Since the entire reason for defining
> > this overload is to avoid reallocation, shouldn't the returns clause
> > specify that we chose an option that doesn't reallocate if one exists?
>
> Isn't that a quality-of-implementation issue?
>
> The Returns clause specifies semantics, and the semantics seems
> correct.

<nod> The intent was to leave this up to QOI.  For example I'd like to
give the vendor the freedom to even choose lhs.append(rhs) even if it
requires allocation if he believes that the insert would be more
expensive, even if it didn't require reallocation.

The idea is to just be fast and try not to specify how.  Indeed I may
have already over-specified it...

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]