2021-05-16 09:39:22 +08: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
|
|
|
|
|
|
|
|
#include <__config>
|
2021-06-12 14:13:44 +08:00
|
|
|
#include <__debug>
|
2021-05-16 09:39:22 +08:00
|
|
|
#include <__iterator/advance.h>
|
|
|
|
#include <__iterator/concepts.h>
|
|
|
|
#include <__iterator/incrementable_traits.h>
|
2021-06-12 14:13:44 +08:00
|
|
|
#include <__iterator/iterator_traits.h>
|
|
|
|
#include <type_traits>
|
2021-05-16 09:39:22 +08:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
|
2022-02-02 09:16:40 +08:00
|
|
|
# pragma GCC system_header
|
2021-05-16 09:39:22 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
_LIBCPP_BEGIN_NAMESPACE_STD
|
|
|
|
|
2021-05-29 01:53:54 +08:00
|
|
|
template <class _InputIter>
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX14
|
|
|
|
typename enable_if<__is_cpp17_input_iterator<_InputIter>::value, _InputIter>::type
|
|
|
|
prev(_InputIter __x, typename iterator_traits<_InputIter>::difference_type __n = 1) {
|
|
|
|
_LIBCPP_ASSERT(__n <= 0 || __is_cpp17_bidirectional_iterator<_InputIter>::value,
|
|
|
|
"Attempt to prev(it, n) with a positive n on a non-bidirectional iterator");
|
|
|
|
_VSTD::advance(__x, -__n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
2022-02-01 01:04:08 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_CONCEPTS)
|
2021-05-16 09:39:22 +08: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-04 09:49:24 +08:00
|
|
|
// [range.iter.op.prev]
|
|
|
|
|
2021-05-16 09:39:22 +08: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-04 09:49:24 +08:00
|
|
|
namespace __prev {
|
|
|
|
|
2022-01-04 09:28:00 +08:00
|
|
|
struct __fn {
|
2021-05-16 09:39:22 +08:00
|
|
|
template <bidirectional_iterator _Ip>
|
2021-07-20 00:34:56 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI
|
2021-05-16 09:39:22 +08:00
|
|
|
constexpr _Ip operator()(_Ip __x) const {
|
|
|
|
--__x;
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <bidirectional_iterator _Ip>
|
2021-07-20 00:34:56 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI
|
2021-05-16 09:39:22 +08:00
|
|
|
constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n) const {
|
|
|
|
ranges::advance(__x, -__n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <bidirectional_iterator _Ip>
|
2021-07-20 00:34:56 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI
|
2021-05-16 09:39:22 +08:00
|
|
|
constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n, _Ip __bound) const {
|
|
|
|
ranges::advance(__x, -__n, __bound);
|
|
|
|
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-04 09:49:24 +08:00
|
|
|
} // namespace __prev
|
|
|
|
|
|
|
|
inline namespace __cpo {
|
2022-01-04 09:28:00 +08: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-04 09:49:24 +08:00
|
|
|
} // namespace __cpo
|
2021-05-16 09:39:22 +08:00
|
|
|
} // namespace ranges
|
|
|
|
|
2022-02-01 01:04:08 +08:00
|
|
|
#endif // !defined(_LIBCPP_HAS_NO_CONCEPTS)
|
2021-05-16 09:39:22 +08:00
|
|
|
|
|
|
|
_LIBCPP_END_NAMESPACE_STD
|
|
|
|
|
|
|
|
#endif // _LIBCPP___ITERATOR_PREV_H
|