This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR libstdc++/80553 don't allow destroying non-destructible types


On 02/05/17 17:30 +0200, Marc Glisse wrote:
On Tue, 2 May 2017, Jonathan Wakely wrote:

On 02/05/17 10:16 +0100, Jonathan Wakely wrote:
On 28/04/17 13:56 +0100, Jonathan Wakely wrote:
We optimize _Destroy and _Destroy_n to do nothing when the type has a
trivial destructor, which means we do nothing (instead of giving an
error) when trying to destroy types with deleted destructors.

I wonder if this optimisation should even exist. The compiler should
be able to optimise away a loop that just calls trivial destructors,
without help from the library.

The compiler can indeed do that optimisation, even for destructors
like ~T() { } that are empty, but not trivial according to the
language rules. The libstdc++ optimisation does make a difference at
-O0 though. If we get any more bugs in that code I think we should
just remove it though, and let the compiler do the right thing.

Does the compiler manage it for all containers, even those with iterators much more complicated than vector's?

It seems to for std::deque (not very complicated) and std::map
(moderately complicated). I didn't try for something like a
directory_iterator which almost certainly wouldn't get optimised away!

I'd rather keep the special code in the library, if it doesn't cause too much trouble.

Yes, assuming the code's correct now then we might as well keep it,
but if it's a source of too many more bugs then it starts to cause too
much trouble.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]