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!
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 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 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 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 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 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
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
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 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
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,
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/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
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
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
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
17 matches
Mail list logo
