On 01/09/20 3:25 pm, Jonathan Wakely wrote:
On 01/09/20 14:06 +0200, François Dumont wrote:
Hi
No chance to review this small patch ?
I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.
I shouldn't have
On 01/09/20 14:06 +0200, François Dumont wrote:
Hi
No chance to review this small patch ?
I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.
I don't agree with your assertion that you use std::deque when you
Hi
No chance to review this small patch ?
François
On 30/06/20 10:33 pm, François Dumont wrote:
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can
attack from front and back. But currre
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can
attack from front and back. But currrently its implementation makes
it behave differently when starting from a fresh deque. If push_ba
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can attack
from front and back. But currrently its implementation makes it behave
differently when starting from a fresh deque. If push_back then all
goes well, it is copy/move to th
After the recent optimization that went in despite in stage 4 I wonder
why I never got any feedback for this one.
https://gcc.gnu.org/ml/libstdc++/2019-05/msg00166.html
I forgot to note that this is the simplest reply to an old Paolo's
request to recycle std::deque's "nodes". And this one is a
