#7856 closed Bugs (fixed)
pop_front() and pop_back() docs missing
Reported by: | Owned by: | Neil Groves | |
---|---|---|---|
Milestone: | Boost 1.56.0 | Component: | range |
Version: | Boost 1.52.0 | Severity: | Problem |
Keywords: | Cc: |
Description
These iterator_range functions appear to be undocumented.
Change History (6)
comment:1 by , 10 years ago
comment:2 by , 9 years ago
Milestone: | To Be Determined → Boost 1.56.0 |
---|---|
Status: | new → assigned |
That's a great suggestion. I used the names from the Alexandrescu work, but this is better.
comment:3 by , 9 years ago
I like pop_ better, especially as existing code is already using it. The type already indicates it's not actually destroying elements. Just like pop_back() for a vector<T*>.
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I much prefer drop_front and drop_back as it avoids accidentally modifying containers. While I appreciate the frustration of having to modify your code it is a small change to functions that were not documented.
I've modified all of my code that uses these functions in the space of half an hour. I hope that the increased work that you incur is small too.
I've renamed the functions and added tests for these.
comment:5 by , 9 years ago
I'll survive, do the required #ifdef's based on BOOST_VERSION probably won't be pretty.
OK, but the names (at least the ones that get documented) should be changed to
drop_front
anddrop_back
.pop_
xxx implies the element is getting destroyed.