RangesライブラリのRangeとViewとconst修飾の関係についてメモ。まとめ:対象Rangeのconst修飾(要素の変更可否)と、Viewのconst修飾(const-iterableの可否)は異なる概念である。C++20標準ライブラリ提供の一部Rangeアダプタでは、const修飾によりViewとして機能しなくなるものがある。std::views::drop_whileViewを受け取るパラメータでは不用意にconst修飾を行わないこと。Viewは定義上「軽量にコピー/ムーブ」されるオブジェクトのため、パラメータ型は非constな値型とすればよい。下記コードのようにViewをconst修飾しても、対象Range要素がconst修飾されていなければ要素値を書き換え可能。要素書き換えから保護するには、対象Range側をconst修飾する(ここではstd::as_constを利用)。std::views::take(3)とも書ける。ill-formed}const性(const-ness)に関するRangeとViewとの関係性は、コンテナ(container)に対するイテレータ(iterator)、配列(array)に対するポインタ(pointer)に相当する。イテレータやポインタが指す先のconst性は重要視されるが、イテレータやポインタそのものをconst修飾する必要性は低い。View&)するとfilterが適用されたViewを受け取れず、汎用アルゴリズムとしての一般性が失われる*2。C::iterator&を、関数f1はC::iteratorを受け取るインタフェースに相当する。time)」を満たしつつ「const操作のスレッド安全性を担保するオーバーヘッド追加を避ける」というライブラリ設計上の選択による。3より引用(下線部は強調)。1.3.1/p3-4より一部引用(下線部は強調)。Rangesライブラリ仕様のベースとなった、range-v3ライブラリのIssue#385より関連議論を一部引用(下線部は強調)。アダプタが提供される。C++20現在の標準ライブラリでは同等機能は提供されない。グループに区分されている。Range)を渡すと、意図せずコンテナ全体がコピーされてしまうリスクがある。コンセプトで制約すべき。1注目記事はてなブログをはじめよう!yohhoyさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。