std :: list :: reverseにO（n）の複雑さがあるのはなぜですか？

std::listC ++標準ライブラリのクラスの逆関数に線形ランタイムがあるのはなぜですか？二重にリンクされたリストの場合、逆関数はO（1）である必要があると思います。

二重にリンクされたリストを反転するには、ヘッドポインターとテールポインターを切り替えるだけです。

仮説的には、O（1）であったreverse可能性があります。（ここでも仮説的に）リンクされたリストの方向が、リストが作成された元のリストと現在同じか反対かを示すブールリストメンバーがあった可能性があります。

残念ながら、これは基本的に他の操作のパフォーマンスを低下させます（ただし、漸近ランタイムは変更しません）。各操作で、リンクの「次の」ポインタまたは「前の」ポインタのどちらに従うかを検討するためにブール値を調べる必要があります。

これはおそらく比較的頻度の低い操作であると考えられていたため、標準（実装を指示せず、複雑さのみ）は、複雑さを線形にできると規定しました。これにより、「次の」ポインタは常に明確に同じ方向を意味し、一般的なケースの処理を高速化できます。

それは可能性があることOリスト「の意味スワップ可能フラグ格納なる場合（1）prev」および「next各ノードが持つ」ポインタ。リストを逆にすることが頻繁な操作である場合、そのような追加は実際に役立つ可能性があり、現在の標準でそれを実装することが禁止される理由はわかりません。ただし、このようなフラグを指定すると、リストの通常のトラバーサルが（定数係数によってのみ）コストが高くなります。

current = current->next;

でoperator++、リストのイテレータ、あなたはなるだろう

if (reversed)
  current = current->prev;
else
  current = current->next;

これは、簡単に追加することを決めたものではありません。リストは通常​​、逆にされるよりもずっと頻繁にトラバースされることを考えると、標準がこのテクニックを義務付けることは非常に賢明ではありません。したがって、逆演算は線形の複雑さを持つことができます。それは、しかし、ノートを行い、T ∈ O（1）⇒ T ∈ O（nは先に述べたように）ので、あなたの「最適化」を実施し、技術的に認められます。

Javaなどのバックグラウンドを持っている場合は、イテレータが毎回フラグをチェックする必要があるのか​​疑問に思うかもしれません。代わりに、2つの異なるイテレータタイプがあり、どちらも共通の基本タイプから派生していて、適切なイテレータstd::list::beginをstd::list::rbeginポリモーフィックに返すことができませんか？可能ではありますが、イテレータを進めると、間接的な（インライン化が困難な）関数呼び出しになるため、全体がさらに悪化します。Javaでは、とにかくこの価格を定期的に支払っていますが、これも、パフォーマンスが重要な場合に多くの人がC ++を利用する理由の1つです。

コメントでベンジャミンリンドリーが指摘したように、reverseイテレータを無効にすることは許可されていないため、標準で許可されている唯一のアプローチは、ポインタをイテレータ内のリストに戻し、二重間接メモリアクセスを引き起こすことです。

双方向のイテレータをサポートするすべてのコンテナにrbegin（）とrend（）の概念があるので、この質問は疑わしいですか？

イテレータを逆にするプロキシを作成し、それを介してコンテナにアクセスするのは簡単です。

この非操作は確かにO（1）です。

といった：

#include <iostream>
#include <list>
#include <string>
#include <iterator>

template<class Container>
struct reverse_proxy
{
    reverse_proxy(Container& c)
    : _c(c)
    {}

    auto begin() { return std::make_reverse_iterator(std::end(_c)); }
    auto end() { return std::make_reverse_iterator(std::begin(_c)); }

    auto begin() const { return std::make_reverse_iterator(std::end(_c)); }
    auto end() const { return std::make_reverse_iterator(std::begin(_c)); }

    Container& _c;
};

template<class Container>
auto reversed(Container& c)
{
    return reverse_proxy<Container>(c);
}

int main()
{
    using namespace std;
    list<string> l { "the", "cat", "sat", "on", "the", "mat" };

    auto r = reversed(l);
    copy(begin(r), end(r), ostream_iterator<string>(cout, "\n"));

    return 0;
}

予想される出力：

mat
the
on
sat
cat
the

これを考えると、標準委員会はコンテナのO（1）逆順を必要としないため、時間をかけていなかったように思われます。重複を避けます。

ちょうど私の2c。

それは、すべてのノード（n合計）をトラバースし、それらのデータを更新する必要があるためです（更新ステップは確かにですO(1)）。これは全体の操作になりO(n*1) = O(n)ます。

また、すべてのノードの前のポインタと次のポインタを入れ替えます。それが線形を取る理由です。O（1）では、このLLを使用する関数がLLに関する情報も入力として受け取る場合、それが正常にアクセスしているか逆にアクセスしているかのように行うことができます。

アルゴリズムの説明のみ。要素を持つ配列があり、それを逆にする必要があるとします。基本的な考え方は、最初の位置の要素を最後の位置に変更し、2番目の位置の要素を最後から2番目の位置に変更するなど、各要素を反復することです。配列の中央に到達すると、すべての要素が変更されるため、（n / 2）回の反復でO（n）と見なされます。

それは単にリストを逆の順序でコピーする必要があるため、O（n）です。個々のアイテム操作はO（1）ですが、リスト全体にn個あります。

もちろん、新しいリスト用のスペースの設定やその後のポインターの変更などに伴う一定の時間操作があります。一次n因子を含めた場合、O表記は個々の定数を考慮しません。