FIFO を実装している間、次の構造を使用しました。
struct Node
{
T info_;
Node* link_;
Node(T info, Node* link=0): info_(info), link_(link)
{}
};
これは、多くの STL コンテナー (List など) でよく知られているトリックだと思います。これは良い習慣ですか？Node がそのポインターの型を持つメンバーを持っていると言うとき、それはコンパイラーにとって何を意味しますか? これは一種の無限ループですか？
最後に、これが悪い習慣である場合、より良い FIFO を実装する方法を教えてください。
編集：人々、これはすべて実装に関するものです。私はSTLライブラリに十分精通しており、いくつかのライブラリのコンテナをたくさん知っています。良い実装や良いアドバイスをくれる人と話したいだけです。
明らかに、リンクされたリストをキューの基本的な実装として使用しています。それについては特に悪いことは何もありません。
参考までに、実装に関しては、 std::queue 自体が std::deque を基になる実装として使用しています。std::deque は、巧妙に管理された動的配列のブロックで構成される、より洗練されたデータ構造です。次の理由により、リンクされたリストよりも優れています。
これは良い習慣ですか？
特に悪いところは見当たりません。
Node がそのポインターの型を持つメンバーを持っていると言うとき、それはコンパイラーにとって何を意味しますか?
同じクラスのオブジェクトへのポインターを格納するクラスに問題はありません。
最後に、これが悪い習慣である場合、より良い FIFO を実装する方法を教えてください。
私は使うだろうstd::queue;）
宣言されている型のオブジェクトへのポインターは、CとC++の両方で問題ありません。これは、ポインタが固定サイズのオブジェクト（たとえば、32ビットプラットフォームでは常に32ビット整数）であるという事実に基づいているため、ポイント先の型のフルサイズを知る必要はありません。
実際、ポインタを宣言するために完全な型宣言さえ必要ありません。前方宣言で十分です。
class A; // forward declared type
struct B
{
A* pa; //< pointer to A - perfectly legal
};
もちろん、実際にメンバーにアクセスする時点で、スコープ内の完全な宣言が必要です。
#include <A.hpp> // bring in full declaration of class A
...
B b;
b.pa = &a; // address of some instance of A
...
b.pa->func(); // invoke A's member function - this needs full declaration
FIFOについては、を調べてstd::queueください。、、の両方std::listをその目的に使用できますが、他の機能も提供しますstd::deque。std::vector
これは、ノードを実装する 1 つの良い方法です。ノード ポインターは、コンテナー内の次のノードへのリンクを作成するために使用されます。その通りですが、ループを作成するために使用できます。コンテナー内の最後のノードが最初のノードを参照する場合、そのコンテナーを反復すると、すべてのノードがループされます。
たとえば、コンテナーが FIFO キューの場合、ポインターはキュー内の次のノードを参照します。つまり、 の値はlink_class の別のインスタンスのアドレスになりますNode。
値の型Tが高価なコピー コンストラクターを実装している場合、より効率的なNodeクラスは次のようになります。
struct Node
{
T * info_;
Node* link_;
Node(T * info, Node* link=0): info_(info), link_(link)
{}
};
info_が のインスタンスへのポインタになっていることに注意してくださいT。ポインターを使用する背後にある考え方は、ポインターを割り当てる方が複雑なオブジェクトをコピーするよりもコストがかからないということです。
既存の FIFO std::queueを使用できます。