Base class to generate methods for a random-access sequence, similar to a std::array. More...

#include <StlBoilerplate.hpp>

Classes
class	const_iterator
class	iterator

Public Types
using	value_type = ValueType
using	reference = value_type&
using	const_reference = const value_type&
using	pointer = ValueType*
using	const_pointer = const ValueType*
using	reverse_iterator = std::reverse_iterator<iterator>
using	const_reverse_iterator = std::reverse_iterator<const_iterator>
using	difference_type
using	size_type = size_t

Public Member Functions
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
	RandomAccessSequence (const RandomAccessSequence &)=default
	RandomAccessSequence (RandomAccessSequence &&)=default
RandomAccessSequence &	operator= (const RandomAccessSequence &)=default
RandomAccessSequence &	operator= (RandomAccessSequence &&)=default

Detailed Description

template<typename Sequence, typename ValueType, bool DefineComparisons>
class stl_boilerplate::RandomAccessSequence< Sequence, ValueType, DefineComparisons >

Base class to generate methods for a random-access sequence, similar to a std::array.

This class takes the derived class and the value_type of the sequence as template parameters. The third template parameter specifies whether to define comparison operators. Comparisons are required by the standard, but for derived classes with additional functionality the autogenerated ones can give incorrect results.

The derived class must implement size and operator[].

template <typename T>
class SequenceView
    : public stl_boilerplate::RandomAccessSequence<SequenceView<T>, T, true> {
 public:
  SequenceView(const gsl::not_null<T*> data, const size_t size)
      : data_(data), size_(size) {}
 
  size_t size() const { return size_; }
 
  T& operator[](const size_t n) { return *(data_ + n); }
  const T& operator[](const size_t n) const { return *(data_ + n); }
 
 private:
  T* data_{nullptr};
  size_t size_{0};
};

This class provides methods for accessing and modifying elements of the sequence, such as front and begin, as well as iterators and reverse iterators. Methods modifying the sequence itself, such as insert, require explicit implementations.

Member Typedef Documentation

◆ difference_type

template<typename Sequence, typename ValueType, bool DefineComparisons>

using stl_boilerplate::RandomAccessSequence< Sequence, ValueType, DefineComparisons >::difference_type

Initial value:

typename std::iterator_traits<const_iterator>::difference_type

std::iterator_traits

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

src/Utilities/StlBoilerplate.hpp

Classes

Public Types

Public Member Functions

Protected Member Functions

Detailed Description

Member Typedef Documentation

◆ difference_type