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

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)
 
StaticDequeoperator= (const StaticDeque &other)
 
StaticDequeoperator= (StaticDeque &&other)
 
StaticDequeoperator= (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
 
RandomAccessSequenceoperator= (const RandomAccessSequence &)=default
 
RandomAccessSequenceoperator= (RandomAccessSequence &&)=default
 

Detailed Description

template<typename T, size_t Capacity>
class StaticDeque< T, Capacity >

A class implementing the std::deque interface with static storage.

Differences from std::deque:

  • The size of the container cannot be increased above Capacity.
  • Operations moving the entire container are O(n) instead of O(1) in the size and invalidate all references and iterators.
  • 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.


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