gnzlbg / static_vector

A dynamically-resizable vector with fixed capacity and embedded storage
https://gnzlbg.github.io/static_vector
167 stars 21 forks source link

Add full() member function #39

Open viccpp opened 5 years ago

viccpp commented 5 years ago

I propose to add a function

constexpr bool full() const noexcept;

counterpart of empty(). Returns true if size() == capacity(). Such function is natural and useful for all containers with limited capacity.

gnzlbg commented 5 years ago

My private implementation has such a function, but the implementation here is intended to be strictly standard conforming (no extensions).

Such a function would probably be useful for all other containers with size() and capacity() and might need to be part of the general container requirements - that is, adding such a function to the static_vector paper is out-of-scope: a different paper is needed.

Your best bet is to either maintain your own implementation, or write a small paper proposing adding it to the containers in general.

viccpp commented 5 years ago

But this is the first standard container with limited capacity() and variable size(). You have a chance to 'establish practice'.

I don't think that all containers should have such function.

OK. Up to you. Thanks for feedback.

gnzlbg commented 5 years ago

You have a chance to 'establish practice'.

I'll ask around and see if it makes sense to add a poll to the next version of the paper to gather feedback on this. My gut feeling tells me that it might raise too many questions "Should std::vector and std::small_vector have this as well ?" that cannot really be resolved in this proposal.

viccpp commented 5 years ago

"Should std::vector and std::small_vector have this as well ?"

My answer would be: 'They might have this but it's not so useful for them. static_vector::push_back() has strong precondition that user has to check sometimes - !some_long_vector_name.full() is much more convenient and clear than some_long_vector_name.size() < some_long_vector_name.capacity()'

gnzlbg commented 5 years ago

That's a good argument (and having to check for !full() is why my implementation has it).

The question would be whether the people in the room consider that it will still be useful enough for std::vector to guarantee adding it to it as well or not, e.g., std::vector::push_back has widely different performance, exception safety, iteration/reference/pointer invalidation... characteristics depending on whether std::vector::full() would return true or false.

!some_long_vector_name.full() is much more convenient and clear than ome_long_vector_name.size() < some_long_vector_name.capacity()

That's true, but that's not the alternative IMO. The alternative would be for users to write their own full function, and write full(some_long_vector_name) instead, which is pretty much as convenient as some_long_vector_name.full().

I'll ask around and see what some people thoughts on the issue are, and maybe add it to the next paper or put a poll on it.

viccpp commented 5 years ago

vector::full() is confusing. I can still add more elements to the "full" container... It's not the case with static_vector

gnzlbg commented 5 years ago

That's a good point.