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.

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

Inconsistent noexcept-ness of static_vector::reserve #204

Closed
Ukilele opened this issue Dec 18, 2021 · 2 comments
Closed

Inconsistent noexcept-ness of static_vector::reserve #204

Ukilele opened this issue Dec 18, 2021 · 2 comments

Comments

@Ukilele
Copy link

Ukilele commented Dec 18, 2021

According to the documentation of static_vector, its member function reserve should be noexcept. But in fact it is not. The documentation is probably generated from the function declaration at line 540. But this code is only defined when the macro BOOST_CONTAINER_DOXYGEN_INVOKED is defined. When actually calling the function, the overload from the base class (boost::container::vector<...>) gets called, which is defined in vector.hpp, line 1567.

I would be willing to provide a pull request with a fix, but I am not sure what needs to be fixed.
The first option would be to not mention noexcept in the documentation, i.e. remove the BOOST_NOEXCEPT_OR_NOTHROW from line 540. The second option would be to move the reserve-function at line 540 out of the BOOST_CONTAINER_DOXYGEN_INVOKED-block and to always provide an actual definition of it.

@vinniefalco
Copy link
Member

vinniefalco commented Dec 18, 2021

I'm not sure that reserve() can be a no-op. what happens if you try to reserve more than there's capacity? it needs to fail.

@igaztanaga
Copy link
Member

Thanks for the report. Throwing on capacity exhaustion depends on the options used by the container (by default it throws when static capacity is exceeded) so the documentation should reflect this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants