SpECTRE  v2024.09.29
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Modules Pages
CircularDeque< T > Class Template Reference

A class implementing the std::deque interface using a circular buffer to avoid allocations when the size does not exceed a previous allocated capacity. More...

#include <CircularDeque.hpp>

Additional Inherited Members

- Public Types inherited from stl_boilerplate::RandomAccessSequence< StaticDeque< T, Capacity >, T, true >
using value_type = T
 
using reference = value_type &
 
using const_reference = const value_type &
 
using pointer = T *
 
using const_pointer = const T *
 
using reverse_iterator = std::reverse_iterator< iterator >
 
using const_reverse_iterator = std::reverse_iterator< const_iterator >
 
using difference_type = typename std::iterator_traits< const_iterator >::difference_type
 
using size_type = size_t
 
- Public Member Functions inherited from stl_boilerplate::RandomAccessSequence< StaticDeque< T, Capacity >, T, true >
iterator begin () &
 
const_iterator begin () const &
 
const_iterator cbegin () const &
 
iterator end () &
 
const_iterator end () const &
 
const_iterator cend () const &
 
reverse_iterator rbegin () &
 
const_reverse_iterator rbegin () const &
 
const_reverse_iterator crbegin () const &
 
reverse_iterator rend () &
 
const_reverse_iterator rend () const &
 
const_reverse_iterator crend () const &
 
size_type max_size () const
 
bool empty () const
 
reference front ()
 
const_reference front () const
 
reference back ()
 
const_reference back () const
 
reference at (const size_type n)
 
const_reference at (const size_type n) const
 
void begin () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void begin () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void cbegin () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void cbegin () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void end () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void end () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void cend () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void cend () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void rbegin () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void rbegin () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void crbegin () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void crbegin () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void rend () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void rend () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void crend () &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
void crend () const &&=delete
 Not part of the standard, but any attempt to store the results of a call that would match one of these would be undefined behavior. Valid uses would be: use as temporaries, but that can usually be better done through the normal container access; and use in unevaluated contexts, but those should really be explicitly requesting lvalue references if that's what they're checking. Either of these can be easily worked around. If these things happen in code outside our control we may have to reconsider.
 
- Protected Member Functions inherited from stl_boilerplate::RandomAccessSequence< StaticDeque< T, Capacity >, T, true >
 RandomAccessSequence (const RandomAccessSequence &)=default
 
 RandomAccessSequence (RandomAccessSequence &&)=default
 
RandomAccessSequenceoperator= (const RandomAccessSequence &)=default
 
RandomAccessSequenceoperator= (RandomAccessSequence &&)=default
 

Detailed Description

template<typename T>
class CircularDeque< T >

A class implementing the std::deque interface using a circular buffer to avoid allocations when the size does not exceed a previous allocated capacity.

The class is optimized for a small number of elements with many balanced insertions and removals. As such, the capacity is not increased beyond the size required when inserting elements in order to save memory in the steady-state.

Differences from std::deque:

  • Insertions (including during construction) are O(n) if the previous capacity is exceeded and invalidate all references and iterators. Some cases where multiple insertions happen in the same method are optimized to perform only one reallocation.
  • Erasing elements from the front of the queue invalidates all iterators (but not references).

This last point is not a fundamental limitation, but could be corrected with a more complicated iterator implementation if the standard behavior is found to be useful.

Note
This class does not behave like a standard circular buffer, in that insertion operations never overwrite existing elements. The circularness is only a reference to the implementation using circular internal storage to avoid allocations.

The documentation for this class was generated from the following file: