std::contiguous_iterator(3) | C++ Standard Libary | std::contiguous_iterator(3) |
NAME¶
std::contiguous_iterator - std::contiguous_iterator
Synopsis¶
Defined in header <iterator>
template<class I>
concept contiguous_iterator =
std::random_access_iterator<I> &&
std::derived_from</*ITER_CONCEPT*/<I>,
std::contiguous_iterator_tag> &&
std::is_lvalue_reference_v<std::iter_reference_t<I>> &&
std::same_as< (since
std::iter_value_t<I>,
std::remove_cvref_t<std::iter_reference_t<I>> C++20)
> &&
requires(const I& i) {
{ std::to_address(i) } ->
std::same_as<std::add_pointer_t<std::iter_reference_t<I>>>;
};
The contiguous_iterator concept refines random_access_iterator by providing a
guarantee the denoted elements are stored contiguously in the memory.
Iterator concept determination
Definition of this concept is specified via an exposition-only alias template
/*ITER_CONCEPT*/.
In order to determine /*ITER_CONCEPT*/<I>, let ITER_TRAITS<I>
denote I if the
specialization std::iterator_traits<I> is generated from the primary
template, or
std::iterator_traits<I> otherwise:
* If ITER_TRAITS<I>::iterator_concept is valid and names a type,
/*ITER_CONCEPT*/<I> denotes the type.
* Otherwise, if ITER_TRAITS<I>::iterator_category is valid and names a
type,
/*ITER_CONCEPT*/<I> denotes the type.
* Otherwise, if std::iterator_traits<I> is generated from the primary
template,
/*ITER_CONCEPT*/<I> denotes std::random_access_iterator_tag.
* Otherwise, /*ITER_CONCEPT*/<I> does not denote a type and results in
a
substitution failure.
Semantic requirements
Let a and b be dereferenceable iterators and c be a non-dereferenceable
iterator of
type I such that b is reachable from a and c is reachable from b. The type I
models
contiguous_iterator only if all the concepts it subsumes are modeled and:
* std::to_address(a) == std::addressof(*a),
* std::to_address(b) == std::to_address(a) +
std::iter_difference_t<I>(b - a), and
* std::to_address(c) == std::to_address(a) +
std::iter_difference_t<I>(c - a).
Equality preservation
An expression is equality preserving if it results in equal outputs given
equal
inputs.
* The inputs to an expression consist of its operands.
* The outputs of an expression consist of its result and all operands
modified by
the expression (if any).
In specification of standard concepts, operands are defined as the largest
subexpressions that include only:
* an id-expression, and
* invocations of std::move, std::forward, and std::declval.
The cv-qualification and value category of each operand is determined by
assuming
that each template type parameter denotes a cv-unqualified complete non-array
object
type.
Every expression required to be equality preserving is further required to be
stable: two evaluations of such an expression with the same input objects
must have
equal outputs absent any explicit intervening modification of those input
objects.
Unless noted otherwise, every expression used in a requires-expression is
required
to be equality preserving and stable, and the evaluation of the expression
may
modify only its non-constant operands. Operands that are constant must not be
modified.
Implicit expression variations
A requires-expression that uses an expression that is non-modifying for some
constant lvalue operand also implicitly requires additional variations of
that
expression that accept a non-constant lvalue or (possibly constant) rvalue
for the
given operand unless such an expression variation is explicitly required with
differing semantics. These implicit expression variations must meet the same
semantic requirements of the declared expression. The extent to which an
implementation validates the syntax of the variations is unspecified.
Notes¶
contiguous_iterator is modeled by every pointer type to complete object type.
Iterator types in the standard library that are required to satisfy the
LegacyContiguousIterator requirements in C++17 are also required to model
contiguous_iterator in C++20.
See also¶
specifies that a bidirectional_iterator is a random-access
random_access_iterator iterator, supporting advancement in constant time and
(C++20) subscripting
(concept)
2022.07.31 | http://cppreference.com |