2021-05-08 13:02:43 +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_NEXT_H
|
|
|
|
#define _LIBCPP___ITERATOR_NEXT_H
|
|
|
|
|
2022-02-15 02:41:09 +08:00
|
|
|
#include <__assert>
|
2021-05-08 13:02:43 +08:00
|
|
|
#include <__config>
|
|
|
|
#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-08 13:02:43 +08:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
|
2022-02-02 09:16:40 +08:00
|
|
|
# pragma GCC system_header
|
2021-05-08 13:02:43 +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
|
|
|
|
next(_InputIter __x, typename iterator_traits<_InputIter>::difference_type __n = 1) {
|
|
|
|
_LIBCPP_ASSERT(__n >= 0 || __is_cpp17_bidirectional_iterator<_InputIter>::value,
|
|
|
|
"Attempt to next(it, n) with negative n on a non-bidirectional iterator");
|
|
|
|
|
|
|
|
_VSTD::advance(__x, __n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
2022-03-12 23:46:57 +08:00
|
|
|
#if _LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_INCOMPLETE_RANGES)
|
2021-05-08 13:02:43 +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.next]
|
|
|
|
|
2021-05-08 13:02:43 +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 __next {
|
|
|
|
|
2022-01-04 09:28:00 +08:00
|
|
|
struct __fn {
|
2021-05-08 13:02:43 +08:00
|
|
|
template <input_or_output_iterator _Ip>
|
2021-07-20 00:34:56 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI
|
2021-05-08 13:02:43 +08:00
|
|
|
constexpr _Ip operator()(_Ip __x) const {
|
|
|
|
++__x;
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <input_or_output_iterator _Ip>
|
2021-07-20 00:34:56 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI
|
2021-05-08 13:02:43 +08:00
|
|
|
constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n) const {
|
|
|
|
ranges::advance(__x, __n);
|
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <input_or_output_iterator _Ip, sentinel_for<_Ip> _Sp>
|
2022-05-06 01:52:12 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI constexpr _Ip operator()(_Ip __x, _Sp __bound_sentinel) const {
|
|
|
|
ranges::advance(__x, __bound_sentinel);
|
2021-05-08 13:02:43 +08:00
|
|
|
return __x;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <input_or_output_iterator _Ip, sentinel_for<_Ip> _Sp>
|
2022-05-06 01:52:12 +08:00
|
|
|
_LIBCPP_HIDE_FROM_ABI constexpr _Ip operator()(_Ip __x, iter_difference_t<_Ip> __n, _Sp __bound_sentinel) const {
|
|
|
|
ranges::advance(__x, __n, __bound_sentinel);
|
2021-05-08 13:02:43 +08: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-04 09:49:24 +08:00
|
|
|
} // namespace __next
|
|
|
|
|
|
|
|
inline namespace __cpo {
|
2022-01-04 09:28:00 +08:00
|
|
|
inline constexpr auto next = __next::__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-08 13:02:43 +08:00
|
|
|
} // namespace ranges
|
|
|
|
|
2022-03-12 23:46:57 +08:00
|
|
|
#endif // _LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_INCOMPLETE_RANGES)
|
2021-05-08 13:02:43 +08:00
|
|
|
|
|
|
|
_LIBCPP_END_NAMESPACE_STD
|
|
|
|
|
2021-12-06 02:05:21 +08:00
|
|
|
#endif // _LIBCPP___ITERATOR_NEXT_H
|