SpECTRE  v2025.03.17
•All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Modules Pages
Public Member Functions | List of all members
TimeSteppers::ConstBoundaryHistoryTimes Class Referenceabstract
Time Steppers

Access to the list of TimeStepIds in a BoundaryHistory. More...

#include <BoundaryHistory.hpp>

Public Member Functions

virtual size_t size () const =0
 
virtual const TimeStepId & operator[] (size_t n) const =0
 
virtual const TimeStepId & operator[] (const std::pair< size_t, size_t > &step_and_substep) const =0
 
virtual size_t integration_order (size_t n) const =0
 
virtual size_t integration_order (const TimeStepId &id) const =0
 
virtual size_t number_of_substeps (size_t n) const =0
 
virtual size_t number_of_substeps (const TimeStepId &id) const =0
 This returns the same value for any substep of the same step.
 
- Public Member Functions inherited from stl_boilerplate::RandomAccessSequence< ConstBoundaryHistoryTimes, const TimeStepId, false >
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.
 

Additional Inherited Members

- Public Types inherited from stl_boilerplate::RandomAccessSequence< ConstBoundaryHistoryTimes, const TimeStepId, false >
using value_type = const TimeStepId
 
using reference = value_type &
 
using const_reference = const value_type &
 
using pointer = const TimeStepId *
 
using const_pointer = const const TimeStepId *
 
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
 
- Protected Member Functions inherited from stl_boilerplate::RandomAccessSequence< ConstBoundaryHistoryTimes, const TimeStepId, false >
 RandomAccessSequence (const RandomAccessSequence &)=default
 
 RandomAccessSequence (RandomAccessSequence &&)=default
 
RandomAccessSequence & operator= (const RandomAccessSequence &)=default
 
RandomAccessSequence & operator= (RandomAccessSequence &&)=default
 

Detailed Description

Access to the list of TimeStepIds in a BoundaryHistory.

For simplicity of implementation, iterable-container access is not provided for substeps within a step, but is instead provided through additional methods on this class.

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