On 08/21/2017 06:30 PM, Jonathan Wakely wrote:
On 19 August 2017 at 19:49, Avi Kivity wrote:
On 08/19/2017 08:49 PM, Jonathan Wakely wrote:
On 19 August 2017 at 18:02, Avi Kivity wrote:
I noticed that std::deque's move constructor (gcc 7.1) is not noexcept.
Is
this conformant to the standard?
Yes it's conforming, but it sucks.
:(
It's hard to imagine a reasonable deque
implementation that can fail a move.
We have one. Our implementation is never "empty" it always has a table
of pointers even if there are no elements. That means we need to
allocate a new table for the moved-from deque, and allocating can
throw.
I don't think we can change this in an ABI compatible way.
Oh, I assumed no one would do this and wrote a wrapper that just adds the
noexcept, without even checking (a type that uses it requires noexcept
moves).
I guess it's unique_ptr time for me.
I proposed this ABI breaking change for the
--enable-symvers=gnu-versioned-namespace config and nobody replied:
https://gcc.gnu.org/ml/libstdc++/2016-10/msg00017.html
This gets rid of the allocations in the move operations, allowing
"really empty" deques.
It also keeps a single deque node around for reuse, so that using a
deque as a FIFO with a "one in, one out" sequence doesn't keep
deallocating and reallocating.
I'm going to commit this for GCC 8. Longer term I also want to provide
some kind of adaptor so that e.g. __gnu_cxx::deque<T, A> would be an
alias for std::deque<T, __better_deque<A>> and would enable the
changes for the default --enable-symvers=gnu configuration.
That is excellent, thanks. Is it legal for a standard specified function
to be more noexcept than the standard? After all, it can change the
behavior of a program.
