https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #9 from Scott Constable <fidget324 at gmail dot com> --- (In reply to Jonathan Wakely from comment #8) > (In reply to Scott Constable from comment #7) > > (In reply to Jonathan Wakely from comment #1) > > > The allocator requirements say that move construction must be equivalent > > > to > > > copy construction, and allocators should be cheap to copy anyway. I don't > > > consider this a bug. > > > > To be nitpicky, it looks like this equivalence requirement was introduced > > recently in the C++20 draft. I'm compiling using C++14. > > It's a defect report, so applies to previous standards. > > https://wg21.link/lwg2593 > > Applying that change selectively would be madness. Ah, I wasn't aware this was a defect correction. I should have figured that out myself. > > > I agree that allocators should be cheap to copy, but as a general principle > > I think that all objects should be copied only when necessary. This is the > > behavior I have observed in STL containers in libc++, as shown in my example > > above. It just makes sense to me that when an STL container is moved, its > > allocator should be moved, and no copying should be performed. > > And that's exactly what libstdc++ does. Your test fails to distinguish > between copies/moves performed during move construction and other operations. I misstated my argument here. The STL container move invokes one move from the allocator, and this is correct. What I don't understand is why the other copies, e.g. from the container default constructor and destructor, are necessary. Particularly when libc++ does not exhibit this behavior.
