SpECTRE
v2024.09.29
|
A class implementing the std::deque interface with static storage. More...
#include <StaticDeque.hpp>
Public Types | |
using | size_type = typename StaticDeque::size_type |
using | difference_type = typename StaticDeque::difference_type |
using | iterator = typename StaticDeque::iterator |
using | const_iterator = typename StaticDeque::const_iterator |
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 | |
StaticDeque (size_type count) | |
StaticDeque (size_type n, const T &value) | |
template<typename InputIterator , Requires< static_deque_detail::is_input_iterator< InputIterator > > = nullptr> | |
StaticDeque (InputIterator first, InputIterator last) | |
StaticDeque (const StaticDeque &other) | |
StaticDeque (StaticDeque &&other) | |
StaticDeque (std::initializer_list< T > init) | |
StaticDeque & | operator= (const StaticDeque &other) |
StaticDeque & | operator= (StaticDeque &&other) |
StaticDeque & | operator= (std::initializer_list< T > init) |
template<typename InputIterator , Requires< static_deque_detail::is_input_iterator< InputIterator > > = nullptr> | |
void | assign (InputIterator first, InputIterator last) |
void | assign (size_type count, const T &value) |
void | assign (std::initializer_list< T > init) |
size_type | size () const |
size_type | capacity () const |
void | reserve (size_type count) |
void | resize (size_type count) |
void | resize (size_type count, const T &value) |
void | shrink_to_fit () |
T & | operator[] (size_type n) |
const T & | operator[] (size_type n) const |
template<typename... Args> | |
T & | emplace_front (Args &&... args) |
template<typename... Args> | |
T & | emplace_back (Args &&... args) |
template<typename... Args> | |
iterator | emplace (const_iterator position, Args &&... args) |
void | push_front (const T &x) |
void | push_front (T &&x) |
void | push_back (const T &x) |
void | push_back (T &&x) |
iterator | insert (const_iterator position, const T &x) |
iterator | insert (const_iterator position, T &&x) |
iterator | insert (const_iterator position, size_type n, const T &x) |
template<typename InputIterator , Requires< static_deque_detail::is_input_iterator< InputIterator > > = nullptr> | |
iterator | insert (const_iterator position, InputIterator first, InputIterator last) |
iterator | insert (const_iterator position, std::initializer_list< T > init) |
void | pop_front () |
void | pop_back () |
iterator | erase (const_iterator position) |
iterator | erase (const_iterator first, const_iterator last) |
void | swap (StaticDeque &other) |
void | clear () |
void | pup (PUP::er &p) |
template<typename... Args> | |
auto | emplace (const const_iterator position, Args &&... args) -> iterator |
template<typename InputIterator , Requires< static_deque_detail::is_input_iterator< InputIterator > > > | |
auto | insert (const const_iterator position, InputIterator first, const InputIterator last) -> iterator |
template<typename T , size_t Capacity> | |
StaticDeque (StaticDeque< T, Capacity >::WithCapacityTag, const size_t capacity) | |
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. | |
Static Public Member Functions | |
static constexpr size_type | max_size () |
Additional Inherited Members | |
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 with static storage.
Differences from std::deque:
Capacity
.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.