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

#include <History.hpp>

Public Member Functions
virtual void	discard_value (const TimeStepId &id_to_discard) const =0

virtual void	pop_front () const =0

virtual void	clear_substeps () const =0

Public Member Functions inherited from TimeSteppers::ConstUntypedHistory< T >
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
	MutableUntypedHistory (const MutableUntypedHistory &)=default

	MutableUntypedHistory (MutableUntypedHistory &&)=default

MutableUntypedHistory &	operator= (const MutableUntypedHistory &)=default

MutableUntypedHistory &	operator= (MutableUntypedHistory &&)=default

Protected Member Functions inherited from TimeSteppers::ConstUntypedHistory< T >
	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

Additional Inherited Members
Public Types inherited from TimeSteppers::ConstUntypedHistory< T >
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

Detailed Description

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

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

Data cannot be inserted or modified through the type-erased interface. The only mutability exposed is the ability to delete data.

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

Public Member Functions

Protected Member Functions

Additional Inherited Members

Detailed Description