zur Uebung implementiere ich gerade einen Binaeren Suchbaum, jetzt versuche ich am Ende den Speicher moeglichst effizient freizugeben, dazu beuntze ich einen Stack, ist das die effektiviste Methode und ist der Code unten gut so und gibt er wirklich den ganzen Speicher wieder frei?

~bstree()
	{

		if(root!=0)
		{
			std::stack<Node*>s;
			if(root->left!=0)s.push(root->left);
			if(root->right!=0)s.push(root->right);

			while(!s.empty())
			{
				Node *t = s.top();
				s.pop();
				if(t->left!=0)s.push(t->left);
				if(t->right!=0)s.push(t->right);
				std::cout << "Delete: " << t->data << std::endl;
				delete t;

			};

		}

class bstree
{

public:

	bstree():root(0){};
	~bstree()
	{

		if(root!=0)
		{
			std::stack<Node*>s;
			if(root->left!=0)s.push(root->left);
			if(root->right!=0)s.push(root->right);
			delete root;

			while(!s.empty())
			{
				Node *t = s.top();
				s.pop();
				if(t->left!=0)s.push(t->left);
				if(t->right!=0)s.push(t->right);
				std::cout << "Delete: " << t->data << std::endl;
				delete t;

			};

		}

	};
	void add(int data)
	{
		Node *new_node = new Node(data);
		if(root==0)
		{
			root = new_node;
		}
		else
		{
			Node *current = root;
			Node *parent;

			while(current!=0)
			{
				parent  = current;
				current = current->data < data ? current->right : current->left;
			};
			if(data > parent->data)
				parent->right = new_node;
			else
				parent->left = new_node;
		}

	};

private:
	class Node
	{
	public:
		Node(int d):data(d),left(0),right(0){};
		Node *left;
		Node *right;
		int data;
	};
	Node *root;

};

Mit Effektiv meine ich, ist es der gewoehnliche Ansatz einen Stack zu benutzen im den Speicher wieder freizugeben

Nein.

Warum nicht einfach rekursiv Loeschen.

Nun, besonders effizient ist das nicht, soweit ich mich erinnere.

Allerdings würde ein unique_ptr auch nur rekursiv löschen - er ruft (implizit) den Destruktor des Knotens auf. Dieser Destruktor zerstört aber auch die Member, unter denen sich wiederum zwei unique_ptrs befinden, deren Destruktor aufgerufen wird.

Das Problem ist, dass man irgendwie "zurückkehren" muss, zum Elternteil, um zum zweiten Knoten zu kommen, und dann wiederum muss man zurück zum Elternknoten dieses Knotens....

Den Elternteil muss man sich also merken.
Also entweder ein Array, um sich alle höheren Verwandten zu merken, oder Rekursion (da werden die Zeiger automatisch 'zwischengespeichert'.
Oder etwa nicht?

Nun, besonders effizient ist das nicht, soweit ich mich erinnere.

Ja wo du das gerade so erwaehnst, da haette ich jetzt auch selbst drauf kommen koennen.

... Den Elternteil muss man sich also merken

Ja und so. Rekursion halt. Je nach Kenntnisstand hilft ein Buch ueber Algorithmen weiter.

Wieso also zwanghaft die Rekursion vermeiden.
Die Suche im Baum läuft doch auch rekursiv

Warum nicht einfach rekursiv Loeschen.

Nun, besonders effizient ist das nicht, soweit ich mich erinnere.

Doch.

Arcoth schrieb:

Allerdings würde ein unique_ptr auch nur rekursiv löschen - er ruft (implizit) den Destruktor des Knotens auf. Dieser Destruktor zerstört aber auch die Member, unter denen sich wiederum zwei unique_ptrs befinden, deren Destruktor aufgerufen wird.

Das Problem ist, dass man irgendwie "zurückkehren" muss, zum Elternteil, um zum zweiten Knoten zu kommen, und dann wiederum muss man zurück zum Elternknoten dieses Knotens....

Den Elternteil muss man sich also merken.
Also entweder ein Array, um sich alle höheren Verwandten zu merken, oder Rekursion (da werden die Zeiger automatisch 'zwischengespeichert'.
Oder etwa nicht?

Oder links und rechts merken. Oder nur links und rechts zur Schleife machen. Keine Ahnung, weshalb Du aufwärts gehen magst.

Rekursion halte ich hier für angemessen, wenn der Baum ausreichend balanciert ist, daß es nicht zum Stacküberlauf kommen kann. Dem Hardwarestack traue ich hier mehr Speed zu als einem Softwarestack.

MigMig schrieb:

~bstree()
    {
 
        if(root!=0)
        {
            std::stack<Node*>s;
            if(root->left!=0)s.push(root->left);
            if(root->right!=0)s.push(root->right);
           
 
            while(!s.empty())
            {
                Node *t = s.top();
                s.pop();
                if(t->left!=0)s.push(t->left);
                if(t->right!=0)s.push(t->right);
                std::cout << "Delete: " << t->data << std::endl;
                delete t;
 
            };
   
        }

Da haste eine komische Sonderbehandlung der root.

~bstree()
    {
        if(root!=0)
        {
            std::stack<Node*>s;
            s.push(root);//reicht doch und root wird sogar auch gelöscht

            while(!s.empty())
            {
                Node *t = s.top();
                s.pop();
                if(t->left!=0)s.push(t->left);
                if(t->right!=0)s.push(t->right);
                std::cout << "Delete: " << t->data << '\n';//kein endl
                delete t;
             }
        }

Warum nicht einfach rekursiv Loeschen. Per Tiefen-"Suche" zu den Blattknoten und beim rekursiven Aufstieg freigeben. Destruktoren zerstoeren, deiner baut aber erstmal einen Stack auf ... dabei kann eine Exception fliegen. Schlecht.

Hmm.
Genug Speicher ist eigentlich da…

~bstree()
{
    if(!root) return;

    Node* rightmost=root;
    while(rightmost->right)
        rightmost=rightmost->right;

    while(root){
        Node* toDie=root;
        rightmost->right=root->left;
        while(rightmost->right)
            rightmost=rightmost->right;
        root=root->right;
        delete toDie;
    }
}
//ungetestet

Doch.

Doch?
Aber nicht so gut wie eine smarte Schleife, nicht wahr?

Oder links und rechts merken. Oder nur links und rechts zur Schleife machen. Keine Ahnung, weshalb Du aufwärts gehen magst.

Ich kam nicht direkt darauf, wie man es mit einer richtig hübschen Schleife mit O(1) Speicher, wie du es tust, lösen kann.

Doch.

Doch?
Aber nicht so gut wie eine smarte Schleife, nicht wahr?

Das nervt.

Das nervt.

Was nervt?

Auch wenn Rekursion schnell ist, ist es schließlich doch nicht optimal. Und wieso etwas Suboptimales wählen?

Doch.

Doch?
Aber nicht so gut wie eine smarte Schleife, nicht wahr?

Was willste damit aussagen? Falls es das ist, was ich fürchte, haste die Speicherverwaltung nicht mitgerechnet? Es geht nicht darum, eine Zählschleife mit einer rekursion zu vergleichen, sondern es geht auch ums Zwischenspeichern.

Auch wenn Rekursion schnell ist, ist es schließlich doch nicht optimal. Und wieso etwas Suboptimales wählen?

Deine Behauptungen entbehren jeder Tatsache und sind schlicht falsch. Mit Rekursion wird jeder Knoten besucht, du musst alle Knoten besuchen deswegen kann es keinen schnelleren Algorithmus geben. Troll doch woanders.

Genug Speicher ist eigentlich da…

~bstree()
{
    if(!root) return;
    
    Node* rightmost=root;
    while(rightmost->right)
        rightmost=rightmost->right;
    
    while(root){
        Node* toDie=root;
        rightmost->right=root->left;
        while(rightmost->right)
            rightmost=rightmost->right;
        root=root->right;
        delete toDie;
    }
}
//ungetestet

Daran hatte ich auch gedacht und dann verworfen, in der Annahme, dass es zu quadratischer worst-case-Komplexität führt. Aufgeschrieben ist aber klar zu erkenn, dass die Blattsuche niemals zweimal über den gleichen Knoten führt, ist also doch schön linear.

Was mich wundert, ist, daß ich von diesem Trick noch nie auch nur andeutungsweise gelesen habe. Für praktisch eingesetzte Bäume, deren Tiefe man nicht garantieren kann, wie z.B. Spreizbäume, wäre das doch vielleicht eine Idee, zum Standardverfahren zu werden. Tragfähig ist das auf jeden Fall. Die Cache-Lokalität ist ein wenig doof.

Bzw. wenn man keine stabilen Node-Iteratoren braucht kann man damit vermutlich sogar einen änderbaren Baum schön hinbekommen.

Wenn es wirklich performant sein soll dann muss man sowieso nen Pool für die Nodes verwenden und fickt nicht mit new/delete rum. Ein Pool bringt immerhin sauschnelle Allokation, optimale Cache-Lokalität und je nach Inhalt der Nodes auch sauschnelle Deallokation.

~bstree()
{
    if(!root) return;//einfach gut, weil doch viele 
        //Destruktor-Aufrufe auf einem leeren bstree geschehen. 
    Node* r=root;
    while(r){
        if(!r.left){//weg
            Node* toDie=r;
            r=r->right;
            delete toDie;
        }
        else if(!r.right){//weg
            Node* toDie=r;
            r=r->left;
            delete toDie;
        }
        else{//rotieren an der root! Die wird nämlich als nächstes bearbeitet. 
//Ist jetzt ein Stack statt einer Queue für die vertagten Jobs. 
//Gute Vermutung, daß Löschungen relativ nah nach Rotierungen kommen, 
//also der Mist noch im Cache ist. Perfekt für Bäume, die "quasi" ballanciert 
//sind, in normalen Anwendungsfällen "quasi" immer, aber man kann's 
//nicht garantieren. 
            Node* e=r->left->right;
            Node* newR=r->left;
            newR->right=r;
            r->left=e;
            r=newR;
        }
    }
}
//ungetestet

Aber dir ist doch sicher klar dass die logisch komplett äquivalente Abfrage 2 Zeilen darunter sowieso durchgeführt wird und das Ganze keinen Takt langsamer ist?

if(!root) return;//einfach gut, weil doch viele
        //Destruktor-Aufrufe auf einem leeren bstree geschehen.

Aber dir ist doch sicher klar dass die logisch komplett äquivalente Abfrage 2 Zeilen darunter sowieso durchgeführt wird und das Ganze keinen Takt langsamer ist?

Uups!!!

Wie offensichtlich!!!
*lach*

Habe mich ums Rotieren gequält. Bäume sind nicht mein Ding eigentlich. Fast immer gibt es bessere Alternativen. War heldenfroh, es gepackt zu haben. Habe zwar sofort gesehen, daß es so möglich ist, Algos mögen mich irgendwie, aber die Reihenfolge der elemetaren Zuweisungen, nööö, da habe ich keine Intuition. Eher eine Drecksintuition. Hätte an der Hochschule bleiben müssen, damit Doktoranden für mich den lästigen Quark ausarbeiten. *hihi*

Produktivcode wäre das nicht bei mir geworden. Ich schaue mir immer was funktionierendes nochmal später an. Wobei ich dem gcc sogar zutraue, daß er das auch packt, der ist ein Monster.

Wobei ich dem gcc sogar zutraue, daß er das auch packt, der ist ein Monster.

Für den rb-tree jedenfalls nicht, da arbeitet der Algorithmus rekursiv (in-oder mit ausgeschriebener Tail-Rekursion). Da der Baum immer ausbalanciert ist, kann man hier Stacküberläufe ausschliessen. Wie es mit internen Datenstrukturen des Compilers aussieht, weiss ich nicht.

aus /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/bits/stl_tree.h

template<typename _Key, typename _Val, typename _KeyOfValue,
           typename _Compare, typename _Alloc>
    void
    _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
    _M_erase(_Link_type __x)
    {
      // Erase without rebalancing.
      while (__x != 0)
        {
          _M_erase(_S_right(__x));
          _Link_type __y = _S_left(__x);
          _M_destroy_node(__x);
          __x = __y;
        }
    }

volkard schrieb:

Wobei ich dem gcc sogar zutraue, daß er das auch packt, der ist ein Monster.

Für den rb-tree jedenfalls nicht, da arbeitet der Algorithmus rekursiv. Da der Baum immer ausbalanciert ist, kann man hier Stacküberläufe ausschliessen. Wie es mit internen Datenstrukturen des Compilers aussieht, weiss ich nicht.

Ich meinte, das dumme if wegzuoptimieren. Aus dem rekursiven Löschen soll er gar keine andere Version bauen.

~bstree()
{
    auto die = [](Node* p, Node* next) { delete p; return next; };
    Node* r=root;
    while(r){
        if(!r->left) {
_:          die( r, r->right );
            continue;
        }
        if(!r->right) {
            die( r, r->left );
            continue;
        }
        do {
            Node* e=r->left->right;
            Node* newR=r->left;
            newR->right=r;
            r->left=e;
            r=newR;
        } while ( r->left );
        goto _;
    }
}

Edit: nochmal überarbeitet. Jetzt ist der Anfangstest doch nicht nötig.