Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

N3000 unclear about basic_string::assign members

3 views
Skip to first unread message

Bo Persson

unread,
Nov 19, 2009, 6:18:00 PM11/19/09
to
The container requirements in clause 23.2.1
[container.requirements.general] states that a containers allocator
can be replaced by copy assignment and move assignment, depending on
iterator_traits.

For basic_string we also have assign(const basic_string& str) and
assign(basic_string&& str) member functions (21.4.6.3
[string::assign]) that supposedly "replaces the string controlled by
*this with a string of length str.size() whose elements are a copy of
the string controlled by str".

It doesn't say whether it should also replace the allocator, and if
so, under what circumstances. Is assign(const basic_string&) a copy
assignment, or is that role reserved for operator=()?

Bo Persson

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

Pablo Halpern

unread,
Nov 20, 2009, 5:41:55 PM11/20/09
to
On Nov 19, 6:18 pm, "Bo Persson" <b...@gmb.dk> wrote:
> The container requirements in clause 23.2.1
> [container.requirements.general] states that a containers allocator
> can be replaced by copy assignment and move assignment, depending on
> iterator_traits.
>
> For basic_string we also have assign(const basic_string& str) and
> assign(basic_string&& str) member functions (21.4.6.3
> [string::assign]) that supposedly "replaces the string controlled by
> *this with a string of length str.size() whose elements are a copy of
> the string controlled by str".
>
> It doesn't say whether it should also replace the allocator, and if
> so, under what circumstances. Is assign(const basic_string&) a copy
> assignment, or is that role reserved for operator=()?

This is a good point, and I would be happy to file an issue about it.
Before I do, however, it would be good to have a proposed resolution.
The two obvious resolutions are:

1. The allocator of 'this' does not change. This is consistent with C+
+98, but inconsistent with operator=.

2. For those versions of assign() that take a 'const basic_string&'
argument, the allocator follows the same rules as for copy assignment
and for those versions that take a 'basic_string&&' argument, the
allocator follows the same rules as for move assignment.

My instinct is to go with #2, but I don't feel strongly about it.
Other opinions?
- Pablo

Daniel Krügler

unread,
Nov 22, 2009, 1:56:20 PM11/22/09
to
On 20 Nov., 23:41, Pablo Halpern <phalp...@halpernwightsoftware.com>
wrote:

I think that option 2 is both consequent and consistent in the
light of C++0x. The comparison with C++98 in option 1 does not
make much sense to me, because in C++0x we already extended
operator= in the same way regarding allocators.

- Daniel

0 new messages