[libcxx-commits] [PATCH] D61139: (ABI break) Remove could-be-defaulted SMFs from `stack` and `queue` and `priority_queue`.
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed May 1 09:22:09 PDT 2019
Quuxplusone added a comment.
In D61139#1485234 <https://reviews.llvm.org/D61139#1485234>, @ldionne wrote:
> In D61139#1485072 <https://reviews.llvm.org/D61139#1485072>, @Quuxplusone wrote:
>
> > @ldionne: I think adding the macro `_LIBCPP_ABI_CONTAINER_ADAPTERS_ALWAYS_NONTRIVIAL` makes the code "more complicated" because then there will be two different codepaths in need of testing.
>
>
> If we want to make this change, we __have__ to guard it behind a macro because there's no way we're breaking libc++'s ABI v1 for that. And we should already have testers for the libc++ ABI v2 (if someone cares about it), so that shouldn't be a significant increase in complexity.
>
> > [...]
> >
> > However! I think the problem with that idea is that it would make `std::stack<int, fixed_capacity_vector<int, 10>>` no longer trivially-destructible! Right now it's not trivially copyable but it is trivially destructible; after your idea, it would remain non-trivially copyable but it would no longer be trivially destructible. So your idea would sadly be a perf //regression//, not merely the desired perf non-improvement. :(
>
> Are you sure about that? cppreference says <https://en.cppreference.com/w/cpp/language/destructor#Trivial_destructor>:
>
> > The destructor for class T is trivial if all of the following is true:
> >
> > - The destructor is not user-provided (meaning, it is either implicitly declared, or explicitly defined as defaulted on its first declaration)
> > - [...]
>
> In that case, the destructor would be explicitly defined as defaulted on its first declaration (and all the other bullets are satisfied too).
When I said "your idea," what I was referring to was the code you posted,
// Henceforth I'll call this code SNIPPET 1.
// in <__config>:
#if _LIBCPP_ABI_V1
// This macro controls whether container adapters are always non-trivial, regardless of whether the underlying Container is trivial or not. This impacts ABI because of how trivial types are passed as function arguments.
# define _LIBCPP_ABI_CONTAINER_ADAPTERS_ALWAYS_NONTRIVIAL
#endif
// in <queue>
template <class T, class Container = deque<T>>
class queue {
public:
#if defined(_LIBCPP_ABI_CONTAINER_ADAPTERS_ALWAYS_NONTRIVIAL)
~queue() { }
#endif
};
`SNIPPET 1` suffers from the problems I said: (1) it uses a config macro so now there's two codepaths to test, and (2) it changes `queue` from "conditionally trivially destructible" to "never trivially destructible."
So suppose we get rid of the macro. That gives us `SNIPPET 2`:
// Henceforth I'll call this code SNIPPET 2.
// in <queue>
template <class T, class Container = deque<T>>
class queue {
public:
~queue() { }
};
`SNIPPET 2` fixes problem (1) from above, but it still suffers from problem (2) it changes `queue` from "conditionally trivially destructible" to "never trivially destructible."
Repository:
rCXX libc++
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61139/new/
https://reviews.llvm.org/D61139
More information about the libcxx-commits
mailing list