![](/img/trans.png)
[英]How do you handle iterator/const_iterator mismatches when passing ranges to C++ algorithms?
[英]Why do the new ranges remove_* algorithms move the first iterator?
當我注意到以下行時,我正在閱讀std::ranges::remove
的 MSVC STL 實現:
_First = _RANGES _Find_if_unchecked(_STD move(_First), _Last, _Pred, _Proj);
實際上, cppreference在其“可能的實現”中也有以下行:
first = ranges::find_if(std::move(first), last, pred, proj);
令我困惑的是,我幾乎從未見過有人移動迭代器; 它們通常復制起來很便宜(或者至少應該是),即使這是一個復制問題,我們也可以采用通用引用並將迭代器std::forward
給find_if
嗎?
與簡單地按值傳遞相比,強制轉換為右值引用有什么優勢?
ranges::find_if
接受input_iterator
,它不一定是可copyable
的(標准中的一個例子是basic_istream_view::iterator
)。
在C++20的迭代器系統中,只有model forward_iterator
這樣的迭代器保證是可復制的,所以這里需要std::move
。
即使這是副本問題,我們也可以采用通用引用並將 std::forward 迭代器改為 find_if 嗎?
迭代器通常按值傳遞。
當第first
迭代器不能保證可復制時,我們需要通過std::move
將其所有權轉移給ranges::find_if
,並通過其返回重新接受其所有權。
(盡管在您的示例中std::move
可以省略,因為ranges::remove
已經需要forward_iterator
)
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.