SpECTRE
v2024.09.29
|
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 | |
RandomAccessSequence & | operator= (const RandomAccessSequence &)=default |
RandomAccessSequence & | operator= (RandomAccessSequence &&)=default |
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:
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.