Ensure implementation is up to spec #55
Conversation
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…for [container.rev.reqmts]
wusatosi
requested review from
camio,
Hels15 and
DeveloperPaul123
as code owners
| { | ||
| for (auto &&__e : __x) | ||
| emplace_back(::std::move(__e)); | ||
| } | ||
|
|
||
| constexpr inplace_vector &operator=(const inplace_vector &__x) | ||
| requires(__N == 0) | ||
| requires(__N == 0 || __iv_detail::__trivial_copy_assignment<__T>) |
There was a problem hiding this comment.
Why is it that for assignment you are using concepts (trivial_copy/move_assignment) while for the constructors you are using type traits (is_trivially_copy/move_constructible)?
There was a problem hiding this comment.
Its simply too much to write the full requirement here in-line.
I do think there should be a better name than __trivial_copy_assignment.
There was a problem hiding this comment.
I'd argue it is less confusing if you list the individual requirements here. The difficulty finding a good name already indicates that __trivial_copy_assignment is not a good concept. Further disadvantages are:
- You have to look up in a different place what the concept means
- You have to get your head around why there is a concept in the first place. Is there something going on with assumption? How does this relate to the requirements from the specification?
It may be easier to write than you think:
- You can leave out is_trivially_destructible, since is_trivially_copyable already implies that (https://en.cppreference.com/w/cpp/language/classes#Trivially_copyable_class). However, I would still write it to have an easily reviewable alignment with the specification.
- You do not have to write a requires clause in the negative case at all. Overload resolution will always pick the more constrained version when it fits.
There was a problem hiding this comment.
Thanks for the comment, I do not know that overload resolution would pick the more constraint candidate, I will adopt your suggestion.
There was a problem hiding this comment.
I think I have to include the negation part, I am unable to compile without the negation, compiler complains ambiguous overload for 'operator='.
There was a problem hiding this comment.
Suggestion adopted in 5b955bc
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| #if 0 | ||
|
|
||
| template <typename T> class InplaceVectorSMFs : public ::testing::Test { | ||
| public: | ||
| using IV = beman::inplace_vector::inplace_vector<T, 10>; | ||
| using IV0 = beman::inplace_vector::inplace_vector<T, 0>; | ||
|
|
||
| struct InputIterator { | ||
| using difference_type = std::ptrdiff_t; | ||
| using value_type = T; | ||
| using iterator_category = std::input_iterator_tag; | ||
|
|
||
| T step; | ||
| explicit constexpr InputIterator(T n) noexcept : step(n) {} | ||
| constexpr InputIterator &operator++() noexcept { | ||
| ++step.value; | ||
| return *this; | ||
| } | ||
| constexpr InputIterator operator++(int) noexcept { | ||
| auto prev = *this; | ||
| ++(*this); | ||
| return prev; | ||
| } | ||
| constexpr T operator*() const noexcept { return step; } | ||
| constexpr bool operator==(InputIterator const &) const noexcept = default; | ||
| }; | ||
| static_assert(std::input_iterator<InputIterator>); | ||
| }; | ||
|
|
||
| using AllTypes = | ||
| ::testing::Types<Trivial, NonTriviallyDefaultConstructible, | ||
| NonTriviallyCopyConstructible, | ||
| NonTriviallyMoveConstructible, NonTriviallyCopyAssignable, | ||
| NonTriviallyMoveAssignable, TriviallyAssignable, |
There was a problem hiding this comment.
@jbab is there any update for this part of the test?
|
The only thing left should be [sequence.reqmts] |
The goal of this PR is to add basic spec tests so the implementation would be minimally useable.
It would be fine to update the implementation itself in this branch.
See spec: https://eel.is/c++draft/inplace.vector
Meant to replace #46 which I accidentally broke.
cc: @jbab