完全にあなたと同意します。答えは簡単だと思います: const 値が使用するのに適した const_iterators を使用し、その逆も同様です。const_iterators に反対している人は、一般的に const に反対しているに違いないと私には思えます...
これは少し異なる見方です。特定のコレクションへConst_iteratorのポインターとしてそれを渡し、コレクションも渡す場合、ほとんど意味がありません。Meyer氏は、コレクションインスタンスのほとんどのメンバー関数では使用できないことを具体的に述べていました。その場合は、昔ながらのが必要になります。ただし、コレクションへのハンドルがない場合、2つの違いは、が指すものを変更できることと、が参照するオブジェクトを変更できないことだけです。const_iteratoriteratoriteratorconst_iterator
iteratorつまり...コレクションと位置をコレクションに渡してアルゴリズムに渡すときはいつでも使用したいとします。基本的に、次のような署名：
void some_operation(std::vector<int>& vec, std::vector::const_iterator pos);
あまり意味がありません。暗黙のステートメントはsome_operation、基になるコレクションを自由に変更できますが、どのpos参照を変更することは許可されていないということです。それはあまり意味がありません。これが本当に必要な場合posは、イテレータではなくオフセットにする必要があります。
反対に、STLのアルゴリズムのほとんどは、イテレーターのペアによって指定された範囲に基づいています。iteratorコレクション自体が渡されることはないため、との違いはconst_iterator、コレクション内の値をイテレータを介して変更できるかどうかです。コレクションへの参照がなければ、分離はかなり明確です。
うまくいけば、それは物事を泥のように明確にしました;）
私は一般的にconstnessを好みますが、最近、const_iteratorsとの難問に遭遇し、私の「常にconstを使用することは可能でした」という哲学を混乱させました。
MyList::const_iterator find( const MyList & list, int identifier )
{
// do some stuff to find identifier
return retConstItor;
}
const list参照を渡すには、constイテレータのみを使用する必要があるため、findを使用すると、結果に対して何もできなくなりますが、findがリストを変更しないことを表現するだけで、結果を確認できます。渡されました。
それでは、スコット・メイヤーズのアドバイスが、恒常性から逃れることが不可能になるこのような問題に関係しているのではないかと思います。私が理解していることから、いくつかの内部の詳細のために、単純なキャストでconst_iteratorsを（確実に）un-constすることはできません。これも（おそらく関連して）問題になります。
これはおそらく関連性があります：const_iteratorのconstnessを削除する方法は？
Meyer のこの特定の声明を特別に考慮する必要はないと思います。変更しない操作が必要な場合は、const_iterator. それ以外の場合は、通常のiterator. ただし、1 つの重要な点に注意してください。イテレータ、つまり 1 と 1 を決して混在constさせないでくださいnon-const。後者のことを知っていれば大丈夫です。
そのリンクを読むと、マイヤーズは基本的に、const_iterator を介して変更を加えることができないため、interator の方が const_interator よりも優れていると言っているようです。
しかし、それが彼の言っていることなら、マイヤーズは実際には間違っています。これがまさに、表現したいときに const_iterator が iterator よりも優れている理由です。