On 08/12/16 21:40 +0100, François Dumont wrote:
On 06/12/2016 12:54, Jonathan Wakely wrote:
On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't
copy _M_color. Shouldn't we capture it along with all the other
_M_header information ?
On 06/12/2016 12:54, Jonathan Wakely wrote:
On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't copy
_M_color. Shouldn't we capture it along with all the other _M_header
information ?
Is it needed? I think the current code does the
On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't copy
_M_color. Shouldn't we capture it along with all the other _M_header
information ?
Is it needed? I think the current code does the right thing, doesn't
it? I'd prefer not to ch
On 17/11/2016 18:52, Jonathan Wakely wrote:
On 28/10/16 21:42 +0200, François Dumont wrote:
+ template
+struct _Rb_tree_key_compare
+{
+ _Key_compare_M_key_compare;
+
+ _Rb_tree_key_compare()
+ _GLIBCXX_NOEXCEPT_IF(
+ is_nothrow_default_constructible<_Key_compar
On 28/10/16 21:42 +0200, François Dumont wrote:
/**
* @brief %Map move constructor.
- * @param __x A %map of identical element and allocator types.
*
- * The newly-created %map contains the exact contents of @a __x.
- * The contents of @a __x are a va
Any feedback regarding this patch ?
François
On 02/11/2016 22:37, François Dumont wrote:
Hi
Here is an updated proposal, I realized that the newly introduced
_M_move_data can be also used in the swap implementation.
Let me know if you prefer without it or not.
François
On 28/10/2
