Was iss'n da los?

  • zerm schrieb:

    Ich versteh das mit dem uninitialisierten static parentNode aber auch gar nicht. Kann da nicht undefiniertest passieren?

    Hum, musste jetzt echt mal ins C99 nachschauen. Tatsächlich werden static-pointer, wenn nicht explizit initialisiert, standardmässig mit NULL angenommen. Man lernt auch immer was dazu ;) Ich werde es in Zukunft dennoch immer explizit hinschreiben ;)
    ♥C++

  • zerm schrieb:

    zerm schrieb:

    Ich versteh das mit dem uninitialisierten static parentNode aber auch gar nicht. Kann da nicht undefiniertest passieren?

    Hum, musste jetzt echt mal ins C99 nachschauen. Tatsächlich werden static-pointer, wenn nicht explizit initialisiert, standardmässig mit NULL angenommen. Man lernt auch immer was dazu ;) Ich werde es in Zukunft dennoch immer explizit hinschreiben ;)


    Das muss so sein, denn sonst wären alle statics relativ sinnfrei und könnten besser gleich als global deklariert werden.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • zerm schrieb:

    zerm schrieb:

    Ich versteh das mit dem uninitialisierten static parentNode aber auch gar nicht. Kann da nicht undefiniertest passieren?

    Hum, musste jetzt echt mal ins C99 nachschauen. Tatsächlich werden static-pointer, wenn nicht explizit initialisiert, standardmässig mit NULL angenommen. Man lernt auch immer was dazu ;) Ich werde es in Zukunft dennoch immer explizit hinschreiben ;)

    Ist auch sauberer, ich war (bzw. bin) mir in dem Fall aber absolut sicher, das der Zeiger sofort auf ein gültiges Objekt zeigt, dann ist es ok für mich.

  • Thallius schrieb:

    zerm schrieb:

    zerm schrieb:

    Ich versteh das mit dem uninitialisierten static parentNode aber auch gar nicht. Kann da nicht undefiniertest passieren?

    Hum, musste jetzt echt mal ins C99 nachschauen. Tatsächlich werden static-pointer, wenn nicht explizit initialisiert, standardmässig mit NULL angenommen. Man lernt auch immer was dazu ;) Ich werde es in Zukunft dennoch immer explizit hinschreiben ;)


    Das muss so sein, denn sonst wären alle statics relativ sinnfrei und könnten besser gleich als global deklariert werden.

    Gruß

    Claus

    Nö, wieso?
    Vollkommen legitim:

    C-Quellcode

    1. static int counter = 10;
    2. if(counter==0) {
    3. //...
    4. } else {
    5. --counter;
    6. }

    Natürlich funktioniert static int counter=0; genauso, als würdest Du das =0 weglassen (wie ich grade gelernt habe...).
    ♥C++

  • zerm schrieb:

    [/code]
    Natürlich funktioniert static int counter=0; genauso, als würdest Du das =0 weglassen (wie ich grade gelernt habe...).


    schon, aber das machts dann ja noch verwirrender, weil man davon ausgeht, daß beim Aufruf der Funktion die Variable auf den Wert gesetzt wird, was ja gar nicht stimmt, wenn sie zum zweiten mal aufgerufen wird....

    Naja wie ich schon sagte. Ich benutze eigentlich sehr selten statics. Gibt ganz wenige Situationen wo sie den Code übersichtlicher machen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Ne, haut nicht so hin die quick'n dirty-Methode, parent stimmt nicht immer, egal ich machs jetzt ordentlich mit parent für jeden Node.

    Eine Frage noch, wie ist das mit dem parent wenn ich den Baum speichern (decodeObjectForKey, encodeObject) will. Mir fehlt da ja der Zeiger.
    Also müsste ich beim Start, den Baum händisch aufbauen, oder ??

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von wolf_10de ()

  • öhm wieso sollte das ein problem sein? du encodest das das root objekt oder halt den parent und diese serializieren ihre childs selbst?

    btw löst der archiver cyclen etc selber auf

    nur nebenbei ich würde das löschen von leafs und childs auch den parents überlassen die kennen doch ihre childs und können die entsprechend freigeben? .. die wieder herum ihre childs freigeben können etc...
    snafu
    :() { :|: &};:
    sometimes i dream in hex
    Obey gravity! Because its a law!

  • Die Parents müssen die Childs garnicht explizit löschen. Du musst einfach eine zyklische Referenz vermeiden, sprich der Zeiger den ein Kindknoten auf seinen Elternknoten hat, darf nicht retained werden, sonst retainen sich parent und child gegenseitig. Also, Parent hat ein Array mit Childs, welche eben auch vom Array retained werden. Wenn der RC des Elternobjekts auf 0 geht, wird dieses Array in der dealloc released, womit sein RC auch auf 0 geht, damit wieder alle Childs ein release bekommen usw. Damit schlägt dealloc bis zum hintersten Blatt durch.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Leute, brauchen wir jetzt echt einen Riesenthread für einen Baum, der mit NSArray-Instanzen implementiert ist? Übrigens heißt es children, nicht childs. ;) Und wozu man einen Up-Pointer braucht, habe ich jetzt auch noch nicht verstanden. Die Struktur selbst verlangt es sicherlich nicht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Leuts macht euch locker! natürlich brauch ein leaf einen Zeiger auf seinen parent. Weil parent seine leafs lösche und nicht anders herrum.
    Ob das nun childs oder children heißt ist mir ziemlich juck, auf jeden Fall funktioniert es einwandrei, ohne gegenseitig hochgeschaukelte retain-counts

    Ob wir einen Riesenthread für einen Baum brauchen, weiß ich nicht, ursprünglich ging es um was anderes, wenns ausufert, dann ist es wie so oft hier...

  • wolf_10de schrieb:

    Leuts macht euch locker! natürlich brauch ein leaf einen Zeiger auf seinen parent. Weil parent seine leafs lösche und nicht anders herrum.

    Wenn der Parent seine Leafs löscht, dann muss der Parent seine Leafs kennen, nicht anders herum. Der Parent braucht also Zeiger auf seine children. (Es müssen ja nicht Leafs sein, sondern es kann sich auch um Teilbäume handeln.) Wenn du gerade nur den Leaf bekommst ("delete yourself in your parent") dann brauchst du einen Up-Pointer, damit er das seinem Parent sagen kann. Das hat aber nichts mit der Baumstruktur zu tun, sondern damit, dass du nur den Leaf kennst. Es kan auch ansonsten Gründe für einen Up-Pointer geben. Das liegt aber alles nicht im Baum begründet.

    Die Krux in dem Code fängt schon damit an, dass du das alles in einer rekursiven Actionmethode machen willst. Überlege dir mal, was das semantisch bedeutet … Das sind rekursive Nutzerinteraktionen. Viel besser ist es, die Löschmethode in deine Nodes zu verschieben und diese rekursiv laufen zu lassen. Das musst du aber nur tun, wenn du etwas zusätzlich beim Löschen machen willst. Einfach für die Speicherverwaltung läuft das automatisch, wie Manfred schon sagte.

    wolf_10de schrieb:

    Ob das nun childs oder children heißt ist mir ziemlich juck, auf jeden Fall funktioniert es einwandrei, ohne gegenseitig hochgeschaukelte retain-counts

    Ob wir einen Riesenthread für einen Baum brauchen, weiß ich nicht, ursprünglich ging es um was anderes, wenns ausufert, dann ist es wie so oft hier...

    Es geht ja nicht darum, dass wir vom Thema abkommen.

    Aber ich habe mich einfach gewundert.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?