On 5/21/20 3:17 PM, Andrey Semashev via Boost wrote:
Hi,
Some time ago I have proposed to include ring_queue and small_ring_queue containers to Boost.Container:
https://github.com/boostorg/container/pull/121
The ring queues work similarly to std::queue with the main difference being that they use a ring buffer internally to store elements. The small_ring_queue also allows to allocate a static storage for a fixed amount of elements. The benefit of this is that dynamic memory allocations can be practically avoided when the number of enqueued elements does not exceed some limit.
In his reply in that PR Ion was not very enthusiastic about including these containers into Boost.Container mostly because (a) there was presumably not much interest from users and (b) because the current implementation requires C++17 while Boost.Container supports C++03.
I would like to ask if there is interest in the community for these kinds of containers. I know I would find them useful, and at least one person commented in the PR to the same effect. However, I would still like to see if more people need this.
If there is interest, what would be the preferred course of action?
1. Should we work on inclusion into Boost.Container or maybe some other library? Candidates? Boost.CircularBuffer was mentioned in the PR, although I'm not sure it is suitable for these components. Creating a new submodule is also a possibility, although it seems like an overkill.
2. Somewhat related to p.1, what minimum C++ version is preferred. E.g. if we agree that Boost.Container is the right place for these components, I could work on lowering minimum C++ version, although C++03 would complicate things considerably.
Thanks.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
FWIW - I made a ring_view library as part of my talk on how to document your own library. Interesting features: a) It has almost no features - simplest possible implement b) library user provides his own fixed size storage c) so there's not allocation d) supports any pair of forward iterators. So it isn't dependent on the container type the user might prefer. std::array works just fine. e) it's very simple - just one header file - though it depends on a couple others. f) Documentation is already written! You can download the talk, slides and library here: http://www.rrsd.com/software_development/boost/CppCon%202017/CppCon%202017.z... Robert Ramey