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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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


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

On 20 Nov., 23:41, Pablo Halpern <phalp...@halpernwightsoftware.com>
wrote:
> 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

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




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