2021-05-16 01:39:22 +00:00
|
|
|
// -*- C++ -*-
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef _LIBCPP___ITERATOR_PREV_H
|
|
|
|
#define _LIBCPP___ITERATOR_PREV_H
|
|
|
|
|
2022-02-14 13:41:09 -05:00
|
|
|
#include <__assert>
|
2021-05-16 01:39:22 +00:00
|
|
|
#include <__config>
|
|
|
|
#include <__iterator/advance.h>
|
|
|
|
#include <__iterator/concepts.h>
|
|
|
|
#include <__iterator/incrementable_traits.h>
|
2021-06-12 06:13:44 +00:00
|
|
|
#include <__iterator/iterator_traits.h>
|
2022-12-21 00:07:17 +01:00
|
|
|
#include <__type_traits/enable_if.h>
|
2021-05-16 01:39:22 +00:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
|
2022-02-01 20:16:40 -05:00
|
|
|
# pragma GCC system_header
|
2021-05-16 01:39:22 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
_LIBCPP_BEGIN_NAMESPACE_STD
|
|
|
|
|
2023-08-15 12:19:05 -07:00
|
|
|
template <class _InputIter, __enable_if_t<__has_input_iterator_category<_InputIter>::value, int> = 0>
|
2022-08-19 13:08:01 +02:00
|
|
|
inline _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX17 _InputIter
|
2021-05-28 17:53:54 +00:00
|
|
|
prev(_InputIter __x, typename iterator_traits<_InputIter>::difference_type __n = 1) {
|
2024-01-05 16:29:23 -08:00
|
|
|
// Calling `advance` with a negative value on a non-bidirectional iterator is a no-op in the current implementation.
|
|
|
|
// Note that this check duplicates the similar check in `std::advance`.
|
|
|
|
_LIBCPP_ASSERT_PEDANTIC(__n <= 0 || __has_bidirectional_iterator_category<_InputIter>::value,
|
|
|
|
"Attempt to prev(it, n) with a positive n on a non-bidirectional iterator");
|
2021-05-28 17:53:54 +00:00
|
|
|
std::advance(__x, -__n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
#if _LIBCPP_STD_VER >= 20
|
2021-05-16 01:39:22 +00:00
|
|
|
|
[libc++] [ranges] Add namespace __cpo to ranges::{advance,next,prev}.
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
2022-01-03 20:49:24 -05:00
|
|
|
// [range.iter.op.prev]
|
|
|
|
|
2021-05-16 01:39:22 +00:00
|
|
|
namespace ranges {
|
[libc++] [ranges] Add namespace __cpo to ranges::{advance,next,prev}.
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
2022-01-03 20:49:24 -05:00
|
|
|
namespace __prev {
|
|
|
|
|
2022-01-03 20:28:00 -05:00
|
|
|
struct __fn {
|
2021-05-16 01:39:22 +00:00
|
|
|
template <bidirectional_iterator _Ip>
|
|
|
|
_LIBCPP_HIDE_FROM_ABI constexpr _Ip operator()(_Ip __x) const {
|
|
|
|
--__x;
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <bidirectional_iterator _Ip>
|
|
|
|
_LIBCPP_HIDE_FROM_ABI constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n) const {
|
|
|
|
ranges::advance(__x, -__n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <bidirectional_iterator _Ip>
|
2022-05-05 19:52:12 +02:00
|
|
|
_LIBCPP_HIDE_FROM_ABI constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n, _Ip __bound_iter) const {
|
|
|
|
ranges::advance(__x, -__n, __bound_iter);
|
2021-05-16 01:39:22 +00:00
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
[libc++] [ranges] Add namespace __cpo to ranges::{advance,next,prev}.
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
2022-01-03 20:49:24 -05:00
|
|
|
} // namespace __prev
|
|
|
|
|
|
|
|
inline namespace __cpo {
|
2022-01-03 20:28:00 -05:00
|
|
|
inline constexpr auto prev = __prev::__fn{};
|
[libc++] [ranges] Add namespace __cpo to ranges::{advance,next,prev}.
The reason for those nested namespaces is explained in D115315:
> AIUI, this keeps the CPO's own type from ADL'ing into the `std::ranges`
> namespace; e.g. `foobar(std::ranges::uninitialized_default_construct)`
> should not consider `std::ranges::foobar` a candidate, even if
> `std::ranges::foobar` is not a CPO itself. Also, of course, consistency
> (Chesterton's Fence, the economist's hundred-dollar bill): if it were
> safe to omit the namespace, we'd certainly want to do it everywhere,
> not just here.
This makes these three niebloids more consistent with the other Ranges
niebloids we've already implemented, such as the `ranges::begin` group
and the `ranges::uninitialized_default_construct` group.
FWIW, we still have three different indentation-and-comment styles
among these three groups.
Differential Revision: https://reviews.llvm.org/D116569
2022-01-03 20:49:24 -05:00
|
|
|
} // namespace __cpo
|
2021-05-16 01:39:22 +00:00
|
|
|
} // namespace ranges
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
#endif // _LIBCPP_STD_VER >= 20
|
2021-05-16 01:39:22 +00:00
|
|
|
|
|
|
|
_LIBCPP_END_NAMESPACE_STD
|
|
|
|
|
|
|
|
#endif // _LIBCPP___ITERATOR_PREV_H
|