Hi
I would like to finally propose this patch before the one on
_Rb_tree, as a separate one.
I have adopted the same evolution on the tracker_allocator with
even a perfect forwarding constructor to allow its usage on top of the
uneq_allocator which take a personality parameter. Doin
Hi
With the patch this time.
I would like to finally propose this patch before the one on
_Rb_tree, as a separate one.
I have adopted the same evolution on the tracker_allocator with
even a perfect forwarding constructor to allow its usage on top of the
uneq_allocator which t
On 25/06/14 21:47 +0200, François Dumont wrote:
I would like to finally propose this patch before the one on
_Rb_tree, as a separate one.
I have adopted the same evolution on the tracker_allocator with
even a perfect forwarding constructor to allow its usage on top of
the uneq_allocator
On 26/06/2014 12:33, Jonathan Wakely wrote:
The _GLIBCXX_USE_NOEXCEPT macro expands to nothing in C++03 mode, so
you might as well omit it in the #else branch.
OK for trunk if you make the tracker_allocator comment correct.
Thanks!
Committed with:
// An allocator facade that intercepts
Hi,
I'm afraid something went badly wrong with this commit, I'm seeing tens
of fails. See eg:
https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
Paolo.
On 26/06/14 23:21 +0200, Paolo Carlini wrote:
Hi,
I'm afraid something went badly wrong with this commit, I'm seeing
tens of fails. See eg:
https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
It seems that uneq_allocator is no longer copy constructible.
Hi,
On 06/27/2014 12:38 AM, Jonathan Wakely wrote:
On 26/06/14 23:21 +0200, Paolo Carlini wrote:
Hi,
I'm afraid something went badly wrong with this commit, I'm seeing
tens of fails. See eg:
https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
It seems that uneq_allocator is no
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
On 27 June 2014 08:27, Paolo Carlini wrote:
> Hi,
>
>
> On 06/27/2014 12:38 AM, Jonathan Wakely wrote:
>>
>> On 26/06/14
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm reverting the last two libstdc++-v3 commits.
Paolo
On 27/06/2014 21:48, Paolo Carlini wrote:
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm revertin
On 27/06/2014 21:48, Paolo Carlini wrote:
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm revertin
On 23/07/14 22:33 +0200, François Dumont wrote:
I have a small question regarding some code next to the one I am
modifying in this patch. I can see lines like:
propagating_allocator() noexcept = default;
When using a default implementation shouldn't we let the compiler
decide if it
On 24/07/2014 10:55, Jonathan Wakely wrote:
On 23/07/14 22:33 +0200, François Dumont wrote:
I have a small question regarding some code next to the one I am
modifying in this patch. I can see lines like:
propagating_allocator() noexcept = default;
When using a default implementatio
On 24 July 2014 21:11, François Dumont wrote:
>
> Yes I have tested with no other changes in my tree and got only those pretty
> printers errors which are unrelated I think:
>
> Python Exception iter() returned non-iterator of type
> '_contained':
> $2 = std::experimental::optional [no contained v
On 23/07/14 22:33 +0200, François Dumont wrote:
On 27/06/2014 21:48, Paolo Carlini wrote:
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a
On 25/07/14 00:19 +0100, Jonathan Wakely wrote:
On 24 July 2014 21:11, François Dumont wrote:
Yes I have tested with no other changes in my tree and got only those pretty
printers errors which are unrelated I think:
Python Exception iter() returned non-iterator of type
'_contained':
$2 = std:
On 29/07/14 22:33 +0100, Jonathan Wakely wrote:
Tested x86_64-linux (thanks to Samual Bronson for testing with
Python3) and committed to trunk.
Oops, Samuel not Samual ... no idea why my fingers typed that wrong!
17 matches
Mail list logo
