| 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 |