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:

src/Time/BoundaryHistory.hpp

Public Member Functions

Additional Inherited Members

Detailed Description