TimeSteppers::ConstUntypedHistory< T > Class Template Reference

Access to the history data used by a TimeStepper in type-erased form. Obtain an instance with History::untyped(). More...

#include <History.hpp>

Public Types
using	WrapperType = T
Public Types inherited from stl_boilerplate::RandomAccessSequence< ConstUntypedHistory< T >, const UntypedStepRecord< T >, false >
using	value_type = const UntypedStepRecord< T >
using	reference = value_type &
using	const_reference = const value_type &
using	pointer = const UntypedStepRecord< T > *
using	const_pointer = const const UntypedStepRecord< 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
virtual size_t	integration_order () const =0
virtual size_t	size () const =0
virtual size_t	max_size () const =0
virtual const UntypedStepRecord< T > &	operator[] (size_t index) const =0
virtual const UntypedStepRecord< T > &	operator[] (const TimeStepId &id) const =0
virtual bool	at_step_start () const =0
UntypedSubsteps	substeps () const
Public Member Functions inherited from stl_boilerplate::RandomAccessSequence< ConstUntypedHistory< T >, const UntypedStepRecord< T >, 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.

Protected Member Functions
	ConstUntypedHistory (const ConstUntypedHistory &)=default
	ConstUntypedHistory (ConstUntypedHistory &&)=default
ConstUntypedHistory &	operator= (const ConstUntypedHistory &)=default
ConstUntypedHistory &	operator= (ConstUntypedHistory &&)=default
Protected Member Functions inherited from stl_boilerplate::RandomAccessSequence< ConstUntypedHistory< T >, const UntypedStepRecord< T >, false >
	RandomAccessSequence (const RandomAccessSequence &)=default
	RandomAccessSequence (RandomAccessSequence &&)=default
RandomAccessSequence &	operator= (const RandomAccessSequence &)=default
RandomAccessSequence &	operator= (RandomAccessSequence &&)=default

Detailed Description

template<typename T>
class TimeSteppers::ConstUntypedHistory< T >

Access to the history data used by a TimeStepper in type-erased form. Obtain an instance with History::untyped().

The methods mirror similar ones in History. See that class for details.

Template Parameters

T	One of the types in MATH_WRAPPER_TYPES

---

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

• src/Time/History.hpp