camper schrieb:

Vor den Anfang zu iterieren ist normalerweise sowieso UB.

UB heißt, der Iterator darf dann sonstwohin zeigen? Bei mir zeigt --list.begin() auf list.end() . Ist das ein Problem?

Wenn man sich drauf verlässt, dass das nicht definiert ist schon.

Swordfish schrieb:

camper schrieb:

Vor den Anfang zu iterieren ist normalerweise sowieso UB.

UB heißt, der Iterator darf dann sonstwohin zeigen? Bei mir zeigt --list.begin() auf list.end() . Ist das ein Problem?

Wenn man sich drauf verlässt, dass das nicht definiert ist schon.

Das ist doch völlig in Ordnung. Nicht definiert heißt nicht, dass ein zufälliger Wert da stehen muss.
Als netter Mensch könntest du aber ein assert benutzen, dass das abfängt.

UB heißt doch, die Implementierung darf machen was sie will?

So ist es. Der Standard legt in keinster Weise fest, was passiert, das heißt das.

Oder meinst du, der Iterator sollte in diesem Falle von -- einfach nicht bewegt werden? Oder std::out_of_range werfen?

Nein, man sollte diese Semantik am Besten gar nicht berücksichtigen. Tu' einfach so, als ob das nie passiert. Das ist auch am effizientesten.

P.S.: Wieso new/delete und kein Allokator?

Kellerautomat schrieb:

Ausserdem koenntest du alle Einfuegeoperationen bzw. Loeschoperationen ueber insert/erase implementieren.

Du sagst "außerdem", d.h. jetzt, mit einer linearen Liste auch schon?

Ja. Implementiere alle Einfuege/Loeschfunktionen ueber die beiden hier:

iterator insert(const_iterator pos, const_reference value);
iterator erase(const_iterator pos);

Sone schrieb:

Wieso new/delete und kein Allokator?

Apropos Allocator: der Standardtyp dafür ist ja std::allocator< T > ... Somit kann/soll(?) ich ihn nicht benutzen, um die Nodes anzulegen, sondern nur für die T s?

Du musst den Allocator rebinden:

template <typename T, typename Allocator = std::allocator<T>>
struct list
{
    typedef typename Allocator::template rebind<node>::other node_allocator_type;

    ...
};

Wozu braucht man die überhaupt?
Wenn man festlegen will, wie der Speicher angefordert wird, kann man doch für eigene Typen operator new überladen...?

Verschiedene Container haben unterschiedliche optimale Allokationsstrategien.
Manchmal will man Speicher vom Heap, manchmal aus einer Arena, dann aus einem dynamischen Pool ...

Nathan schrieb:

Wozu braucht man die überhaupt?
Wenn man festlegen will, wie der Speicher angefordert wird, kann man doch für eigene Typen operator new überladen...?

Verschiedene Container haben unterschiedliche optimale Allokationsstrategien.
Manchmal will man Speicher vom Heap, manchmal aus einer Arena, dann aus einem dynamischen Pool ...

OK, das klingt logisch.

Habe eben begonnen alle ctors á la

explicit list_t( size_type n )
:	head(),
	tail(),
	length()
{
	if( !n )
		return;

	node_t * first_new_node;
	
	try {
		first_new_node = new node_t();
	
	} catch( std::bad_alloc ) {
	
		throw;
	
	} catch( ... ) {
	
		delete first_new_node;
		throw;
	}
	
	node_t * current_new_node = first_new_node;
	node_t * last_new_node = first_new_node;
	
	for( size_type i = n; --i; ) {
	
		try {
			current_new_node->next = new node_t();
		
		} catch( ... ) {
		
			if( !current_new_node->next ) {
			
				current_new_node = first_new_node->next;
			
				while( current_new_node ) {
			
					node_t *next_new_node = current_new_node->next;
					delete current_new_node;
					current_new_node = next_new_node;
				}
			
				delete first_new_node;

				throw;
			}
		}
		
		current_new_node->next->prev = current_node;
		last_new_node = current_new_node = current_new_node->next;
	}

	head = first_new_node;
	tail = last_new_node;
	length = n;
}

umzuschreiben, damit nichts mehr leckt. . o O ( Vielleicht sollt ich mir doch mal Smartpointer anseh'n )

Keine gute Idee. catch(...) throw;-Orgien sind fehleranfällig, und schwer zu lesen. Warum nicht einfach eine Basisklasse/Member verwenden, die fürs Aufräumen zuständig ist?

Swordfish schrieb:

camper schrieb:

Der -- Operator deiner Iteratoen ist ein bisschen seltsam.

Hm. Warum seltsam?

Hatte falsch gelesen. Wenn ein Iteratoreninterface benötigt wird, ist ein Dummyknoten empfehlenswert. Das geht auch noch völlig ohne Overhead, schließlich enthält das Listobjkekt ja bereits eine halben Knoten.

Seit 8 Jahren im Forum und beschäftigt sich noch mit solch einfachen Sachen

Dann schreib' du mal eine std::list -Implementation. Ich habe mich heute auch dran gesetzt, das macht viel Spaß. Und es ist nicht einfach, es elegant, effizient und ordentlich zu machen.
P.S.: AFAIK hatte Swordfish doch eine längere Pause?

lool schrieb:

Seit 8 Jahren im Forum und beschäftigt sich noch mit solch einfachen Sachen

Dann schreib' du mal eine std::list -Implementation. Ich habe mich heute auch dran gesetzt, das macht viel Spaß. Und es ist nicht einfach, es elegant, effizient und ordentlich zu machen.

Jeder sollte das schon einmal gemacht haben. Mit dem Zirkel-Trick und mit Exception-Safety. Unterstützung für std::allocator muss nicht sein ("std STL allocators are painful to work with and lead to code bloat and sub-optimal performance"), entweder nimmt man sein eigenes Allocator-Design oder gar nichts.

Es spricht nichts dagegen, wenn Anfänger wie Sone eine std::list implementieren. Aber nach acht Jahren ist das eigentlich überfällig, das sehe ich genauso wie lool. Ich finde die Reaktion witzig, wie der Hinweis auf Exception-Safety sofort zu try/catch geführt hat. try/catch(...)+rethrow lässt sich immer zu RAII umformen. Sollte auch fast immer gemacht werden.

Sone schrieb:

lool schrieb:

Seit 8 Jahren im Forum und beschäftigt sich noch mit solch einfachen Sachen

Dann schreib' du mal eine std::list -Implementation. Ich habe mich heute auch dran gesetzt, das macht viel Spaß. Und es ist nicht einfach, es elegant, effizient und ordentlich zu machen.

Jeder sollte das schon einmal gemacht haben.

klar. Meine letzte war vor etwa einem Jahr.

Unterstützung für std::allocator muss nicht sein ("std STL allocators are painful to work with and lead to code bloat and sub-optimal performance"), entweder nimmt man sein eigenes Allocator-Design oder gar nichts.

EASTL-Fan?
Es geht mir nicht darum, eine schöne Implementierung zu schreiben, sondern eine möglichst zu std::list äquivalente. Ich habe (AFAIK) nur wenige, kleine Änderungen zu std::list in meinem vorläufigen Extrakt.
(Nehme ich ein eigenes Design werde ich früher oder später auf allocator_traits zurückgreifen, weil auch std::allocator verfügbar sein soll. Und dann ist ein eigenes Design auch bescheuert. Darüber hinaus habe ich mich mit Allokatoren noch nicht viel beschäftigt und sehe deswegen - als Sturkopf - nicht ein, wieso den das STL-Allokator-Design so hässlich und schmerzbringend sein soll)

try/catch(...)+rethrow lässt sich immer zu RAII umformen.

Dann zeige mir, wie man (ohne Performance-Verlust und mit weniger Code, was ja anscheinend das Ziel ist) dasselbe erreicht wie im Code unten.

Hier wäre dann eine (unvollständige) Version meiner Implementierung: http://ideone.com/rJ4sOr
(Schade, die Formatierung ist wieder hinüber.)

?

typedef iterator const const_iterator;

wirklich?

Jeder sollte das schon einmal gemacht haben.

klar. Meine letzte war vor etwa einem Jahr.

Dann sollte sie ja diesmal richtig sein.

Sone schrieb:

Dann zeige mir, wie man (ohne Performance-Verlust und mit weniger Code, was ja anscheinend das Ziel ist) dasselbe erreicht wie im Code unten.

Dann mach du erstmal deine Implementierung ohne Performance-Verlust.

struct Node
        {
                Node *prev,
                     *next;

                pointer data; // WTF?

Die zusätzliche Indirektion bringt hier nichts und schadet nur. Warum ein Pointer?

struct node {
  node *next, // vorwärtsiterieren ist im Zweifelsfall wichtiger als
       *prev; // rückwärtsiterieren
  T data; 
}

Ausserdem sehe ich überall new/delete. Wenn du Allocator willst, dann musst du den auch verwenden.
Tipp: "Du musst den Allocator rebinden" (Zitat von Kellerautomat, Seite 2)

Dann zeige mir, wie man (ohne Performance-Verlust und mit weniger Code, was ja anscheinend das Ziel ist) dasselbe erreicht wie im Code unten.

Prinzipiell: http://ideone.com/NMRpbG
Weniger Code ist nur ein Nebeneffekt, hauptsächlich geht es um die Vorzüge von RAII: Fehlerfreies Ressourcenmanagement.

(Beispiel: dein Code sigsevt)