Naja hier der Code, ist nur bissl auskommentiert, hab ich grade hingekritzelt. Natürlich wird die Funktionsweise anhand von Schaubildern davor erklärt. Damit mein ich also dass die Daten sozusagen in einem Kreis verbunden sind, und dass man deshalb nur den Pointer zum Ende braucht. Und etwa warum der End-Pointer über die Liste hinaus zeigt.

Naja hier der Code:

struct Node 
{
    // pointer to next node (or first element if head)
	Node* next;
	// pointer to previous node (or last element if head)
	Node* prev;
	// stored value (unused if head)
	int value;
};

class List
{
	private:

		Node* _head;
		unsigned _size;

	public:

		List()
		{
			// generating list's end
			_head = new Node;
			_head->next = _head->prev = _head;
			_size = 0;
		}

		// List(List const&) { ... }
		// fehlt absichtlich... Ich will nicht noch die Copy-C'toren erklären

		~List()
		{
			// free all elements
			clear();
			// free head
			delete _head;
		}

		void insert(Node* pos, int value)
		{
			// allocating memory
			Node* newNode = new Node;
			newNode->value = value;
			// revalidating pointers
			newNode->next = pos;
			newNode->prev = pos->prev;
			pos->prev->next = newNode;
			pos->prev = newNode;
			// increasing size
			++_size;
		}

		void push_front(int value) // pop_front/back wär auch noch drin
		{
			insert(begin(), value);
		}

		void push_back(int value)
		{
			insert(end(), value);
		}

		Node* erase(Node* pos)
		{
			// store next element
			Node* returning = pos->next;
			// revalidating pointers
			pos->next->prev = pos->prev;
			pos->prev->next = pos->next;
			// free node
			delete pos;
			// decreasing size
			--_size;
			// return the next element after the erased
			return returning;
		}

		void clear()
		{
			Node* iterator = begin();
			while( iterator != end() ) {
				iterator = erase(iterator);
			}
		};

		Node* begin() // hier eventuell noch const überladung
		{
			return _head->next;
		}

		Node* end() 
		{
			return _head;
		}

		bool empty() const
		{
			return _size == 0;
		}

		unsigned size() const
		{
			return _size;
		}

};

Gruß

Hättest nicht zufällig Lust nen Artikel daraus zu machen?

Muss zuerst meine Präsentation fertig machen... Aber villeicht könnt ich ja mal ne Art Tutorial zur Erstellung von so was machen wo dann auch noch ins Themengebiet der Iteratoren und Templates eingreift. Btw: Artikel für was?

Ich wollte einfach mal wissen ob die Implementierung und die Funktionsweise so ok ist, oder ob ich das was wichtiges vergessen / falsch habe, weil ich das wie gesagt mit einer Präsentation aufbaue. Irgendwelche Standardalgorithmen sind ja noch gar nicht drin.

HumeSikkins schrieb:

* die Kommentare sind größtenteils grausam.

Dacht ich mir auch, wird aber so verlangt vom Lehrer... (soll heißen: eigentlich muss bei dem vor jede Zeile so ein dummes Kommentar)

HumeSikkins schrieb:

* die Liste tut wie ein Value-Type hat aber eine kaputte Kopiersemantik. Also entweder kopieren verbieten oder richtig implementieren.

Weiß ich auch, nur keiner weiß was ein Copy-C'tor ist, deshalb hab ich ihn nicht drin. Villeicht ergänz ich es noch am Ende

HumeSikkins schrieb:

* ein paar asserts wären imo angebracht.

Müsst ich auch noch erklären, meine Vorstellung ist zeitlich beschränkt...

Tja man könnte fast schon sagen bei uns hat keiner Ahnung...

Gruß

Artikel für's C++ Magazin, hatte das auch schon im Lineup, bin aber gerade andersweitig beschäftigt.

Da soll das dann aber sicher eine andere Zielgruppe sein, oder?

Gruß

HumeSikkins schrieb:

* die Kommentare sind größtenteils grausam.

Dacht ich mir auch, wird aber so verlangt vom Lehrer... (soll heißen: eigentlich muss bei dem vor jede Zeile so ein dummes Kommentar)

Kauf ich dir nicht ab. Kein Lehrer der Welt wird schlechte Kommentare guten vorziehen. Wenn du also schon soviel (mehr oder weniger jede Zeile) Kommentieren musst, dann beschreib doch lieber die Idee hinter der Zeile statt die Wirkung des Codes. Letztere steht nämlich bereits genau im C++ Standard beschrieben. Und auch das Englisch erscheint mir etwas holprig zu sein.

Sowas:

// generating list's end
_head = new Node;

ist doch eher verwirrend. Laut Kommentar wird das Ende der Liste erzeugt. Der Code weißt _head einen neuen Knoten zu. Mit Kopf assoziere ich Vorne/Anfang, nicht Ende. Mir ist zwar klar, was du tust (und warum). Aber das nur, weil ich auch schon die ein oder andere Liste implementiert habe und nicht weil ich deine Kommentare bzw. Implementation gelesen habe.

Warum hat deine leere Liste (_size ist ja 0) denn einen Knoten? Und was ist die Bedeutung des Knotens? Oder anders: warum verwendest du ein Sentinel-Knoten nicht z.B. einfach Nullpointer?
Der Standardgrund dafür ist doch der, dass dadurch die Implementation von Methoden wie insert einfacher wird, da keine Sonderfälle berücksichtigt werden müssen.

Das könnte man z.B. kurz und knapp als Kommentar hinschreiben. Dabei würde ich dann noch gleich den Namen head ändern. Schließlich ist head immer der Nachfolger des letzten Knotens der Liste und der Vorgänger des ersten. Damit ist er weder eindeutig Head noch eindeutig Tail und wird deshalb wohl gerne Nil oder ähnlich genannt.

Mal ein kläglicher Versuch:

// The special nil-node acts as a sentinel node. It is the successor
// of a list's tail node and the predecessor of a list's first node.
// Using such a nil-node makes the implementation easier
// because empty lists don't need special treatment.
_nil = new Node;
_nil->next = _nil->prev = _nil;
_size = 0;

Oder was bringt einem ein Kommentar à la: // revalidating pointers
in insert?
Wäre es hier z.B. nicht interessanter zu wissen, dass wir den neuen Knoten
vor dem Knoten pos einfügen?

HumeSikkins schrieb:

Kein Lehrer der Welt wird schlechte Kommentare guten vorziehen.

Achja... Dann sag mir bitte dass kein Lehrer der Welt behauptet...
- dass virtuelle Methoden zur Laufzeit kompilliert werden.
- dass virtuelle Methoden erst zur Laufzeit instanziert werden (die v-table hat er nie erwähnt).
- dass eine Methode keine Übergabeparameter haben darf, die es schon mit selben Bezeichner in der Klasse gibt.
- der nicht weiß, dass MyClass t(); kein Objekt instanziert, sondern eine Funktion deklariert.
- ...

Also ich kennen leider zumindest einen! Ist immer ansichstsache was der Lehrer als gut erachtet. Ist ja jetzt auch egal, hab den Code nur kurz fürs Prinzip erstellt
</offtopic>

Wie gesagt gibt es eine Präsentation, in der erwähne ich dann schon was der Knoten da soll. Ich denke aber der ist nicht nur wegen dem insert(), das macht fast alle Methoden einfacher. Das head hab ich aus der Implementierung die im VC++05 verwendet wird, hab da irgendwie nicht weiter nachgedacht.

Btw: Ich weiß dass meine Kommentare nichts bringen... Normalerweise kommentier ich in Methoden oder Funktionen nie, sondern nur die Funktionsweise davon. Mehr als 10 (Code-)Zeilen kommen da meistens nicht rein, und die lassen sich schnell ohne Kommentare verstehen, wenn man weiß was das ganze zusammen anstellt.

Gruß

Ist immer ansichstsache was der Lehrer als gut erachtet

Das ist sicher richtig. Auf der anderen Seite ist es imo wichtiger sich darauf zu konzentriert was man selbst für gut erachtet. Schließlich steht am Ende ja der eigene Name auf dem Papier/Vortrag/Tutorial und nicht der des Lehrers.
Und die meisten Lehrer/Profs sind doch recht offen wenn es darum geht neue Sichtweisen zu aktzeptieren auch wenn sie von der Lehrermeinung abweichen. Zumindest solange man seine Argumente sachlich fundiert und nicht etwa neunmal klug oder arrogant vorträgt.

Aber bevor das jetzt ausartet: Meine Beiträge waren nur Antworten auf dein:

Ich würd mal gern wissen was ihr von folgenden haltet

und können selbstverständlich ignoriert werden (oder gar totaler quatsch sein).

Aber bevor das jetzt ausartet: Meine Beiträge waren nur Antworten auf dein:

Ich würd mal gern wissen was ihr von folgenden haltet

und können selbstverständlich ignoriert werden (oder gar totaler quatsch sein).

Wie erwähnt das war nur offtopic. Das mit den Kommentaren war natürlich ein wichtiger Kritikpunkt.

erase auf empty gibt dir glaub ich max unsigned.
mit erase(0) macht erase Boom.
List L;
L.erase(begin());
sollte auch nicht das erwartete liefern

Stimmt, das macht alles boom. Man könnte auch einen Pointer auf einen Knoten einder anderen Liste übergeben, dann sieht es zwar noch nach außen gut aus, hat aber innen Boom gemacht.
Das oben genannte macht aber auch bei der STL Boom (soll es ja schließlich, nur die Frage ist wie) - afaik in Form von Asserts.

Gruß