On 25/10/16 21:55 +0200, François Dumont wrote:
Indeed, here is the simplified patch.
But I will come back to this base type for the next patch to
generalize the defaulted constructors and assignment operators.
Tested under Linux x86_64, ok to commit ?
OK for trunk, thanks.
On 24/10/2016 13:03, Jonathan Wakely wrote:
On 12/10/16 22:36 +0200, François Dumont wrote:
On 10/10/2016 23:01, Tim Song wrote:
Trying again...with a few edits.
On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
wrote:
@@ -602,24 +612,32 @@
On 12/10/16 22:36 +0200, François Dumont wrote:
On 10/10/2016 23:01, Tim Song wrote:
Trying again...with a few edits.
On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
wrote:
@@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _Rb_tree_impl : public
Hi
I have run all tests with success. Even if it doesn't get rid of
_GLIBCXX_NOEXCEPT_IF it still limits it to one place.
So is it ok to commit ?
François
On 12/10/2016 22:36, François Dumont wrote:
On 10/10/2016 23:01, Tim Song wrote:
Trying again...with a few edits.
On Mon,
On Wed, Oct 12, 2016 at 4:36 PM, François Dumont wrote:
> On 10/10/2016 23:01, Tim Song wrote:
>>
>> Trying again...with a few edits.
>>
>>> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
>>> wrote:
>>>
>>> @@ -602,24 +612,32 @@
On 10/10/2016 23:01, Tim Song wrote:
Trying again...with a few edits.
On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
wrote:
@@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _Rb_tree_impl : public _Node_allocator
{
_Key_compare
Trying again...with a few edits.
> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
> wrote:
>
> @@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct _Rb_tree_impl : public _Node_allocator
> {
>_Key_compare _M_key_compare;
> -
On 09/10/2016 17:14, Jonathan Wakely wrote:
On 08/10/16 22:55 +0200, François Dumont wrote:
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to compute
conditional noexcept when defaulting
On 09/10/16 16:14 +0100, Jonathan Wakely wrote:
On 08/10/16 22:55 +0200, François Dumont wrote:
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to
compute conditional noexcept when defaulting
On 08/10/16 22:55 +0200, François Dumont wrote:
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to
compute conditional noexcept when defaulting implementations. This
is what I have done in
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to compute
conditional noexcept when defaulting implementations. This is what I
have done in this patch.
The new default constructor on
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to compute
conditional noexcept when defaulting implementations. This is what I
have done in this patch.
The new default constructor on _Rb_tree_node_base is not a problem as
it is not
On 05/10/2016 14:13, Jonathan Wakely wrote:
On 05/10/16 14:10 +0200, Marc Glisse wrote:
On Wed, 5 Oct 2016, Jonathan Wakely wrote:
I added conditional noexcept to maps and sets, but forgot to account
for the comparison function, which could throw when constructed.
IMO you are fighting a
On 05/10/16 14:10 +0200, Marc Glisse wrote:
On Wed, 5 Oct 2016, Jonathan Wakely wrote:
I added conditional noexcept to maps and sets, but forgot to account
for the comparison function, which could throw when constructed.
IMO you are fighting a losing battle. We should implement
On Wed, 5 Oct 2016, Jonathan Wakely wrote:
I added conditional noexcept to maps and sets, but forgot to account
for the comparison function, which could throw when constructed.
IMO you are fighting a losing battle. We should implement noexcept(auto)
(possibly with some private
15 matches
Mail list logo