Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[vector.cons.10] complexity in term of copy constructor calls but T does not need to have constructors #6733

Open
gonzalobg opened this issue Dec 13, 2023 · 3 comments
Open

[vector.cons.10] complexity in term of copy constructor calls but T does not need to have constructors #6733

gonzalobg opened this issue Dec 13, 2023 · 3 comments

Comments

@gonzalobg
Copy link

https://eel.is/c++draft/vector#cons-10 states:

template<class InputIterator>
  constexpr vector(InputIterator first, InputIterator last,
                   const Allocator& = Allocator());
  • Effects: Constructs a vector equal to the range [first, last), using the specified allocator.
  • Complexity: Makes only N calls to the copy constructor of T (where N is the distance between first and last) and no reallocations if iterators first and last are of forward, bidirectional, or random access categories. It makes order N calls to the copy constructor of T and order logN reallocations if they are just input iterators.

But T does not need to be copy constructible.
@jwakely
Copy link
Member

jwakely commented Dec 13, 2023 •
edited

It does need to be copy constructible (Edit: oops, I was thinking of the vector(size_type, const T&) constructor for some reason, not the one clearly shown above!), the point is that copy construction might not use a copy constructor. Some other constructor could be chosen, or it might have no constructors at all, e.g. scalars.

@gonzalobg gonzalobg changed the title [vector.cons.10] complexity in term of copy constructor calls but T does not need to be copy constructible [vector.cons.10] complexity in term of copy constructor calls but T does not need to have constructors Dec 13, 2023
@CaseyCarter
Copy link
Contributor

CaseyCarter commented Dec 13, 2023 •
edited

It does need to be copy constructible

The proper requirement is that T must be Cpp17EmplaceConstructible from iter_reference_t<InputIterator> (https://godbolt.org/z/Wj3Y9xzx1) as stated in [sequence.reqmts]/8. (Yes, [sequence.reqmts]/2.5's requirement that "i and j ... refer to elements implicitly convertible to value_type" is an extraneous "sanity check".)

Maybe the complexity requirement should state that exactly N objects of type T are initialized?

@jwakely
Copy link
Member

jwakely commented Dec 13, 2023

exactly N objects of type T are initialized

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@CaseyCarter @jwakely @gonzalobg