Vererbung, Klassen, verkettete stl::list von zeigern?



  • Braunstein schrieb:

    Hallo,

    Warum willst du in Town eine Liste von Building-Zeigern? Eine Liste auf Objekte tut es hier auch.
    Wenn eine Stadt alle seine Gebäude kontrolliert, muß das einzelne Gebäude doch auch nicht mehr wissen in welcher Stadt es ist.
    Wenn du es unbedingt brauchst speichere in Building einen Zeiger auf das Parent-Town-Objekt.
    };

    naja ganz einfach es ist nich nur eine stadt sondern es werden mehere Städte generiert und jede stadt besitzt gebäude.
    d.h. ich habe eine Liste von Städten in meiner main() und die Städte sollen als attribut eine Liste von Gebäuden haben .. und genau das ist mein problem.
    von daher brauch ich eine Liste von Building-Zeigern als attribut. damit ich ein Building Objekt dynamisch erzeugen kann und in die Building* liste der betreffenden Stadt einfügen kann. von daher nur wie sieht das aus eine verkettete liste von Building*-zeigern...
    also stimmte das schonmal..was ich im kommentar geschrieben hab //Town* refTown; ??



  • Ein Building kann doch eigentlich nur in einer Stadt sein.
    Du brauchst hier keine Liste von Building-Zeigern (Objekte reichen). Die Stadt muß die Liste der Gebäude verwalten (hinzufügen, löschen etc.).
    Was hindert dich denn daran hier

    std::list<Building> buildings;
    

    zu nehmen.
    Da könnte man so ein Gebäude hinzufügen

    buildings.push_back(Building(this)); // Wenn im Konstruktor der zeiger auf Town mitgegeben werden soll
    


  • sten schrieb:

    daher brauch ich eine Liste von Building-Zeigern als attribut. damit ich ein Building Objekt dynamisch erzeugen kann und in die Building* liste der betreffenden Stadt einfügen kann. von daher nur wie sieht das aus eine verkettete liste von Building*-zeigern...

    std::list<Building*> buildings;
    

    ?



  • Ja sicher. Nur warum?
    Bei Zeigern muß er halt immer Gültigkeit prüfen und selber für das Aufräumen sorgen.



  • Braunstein schrieb:

    Ja sicher. Nur warum?
    Bei Zeigern muß er halt immer Gültigkeit prüfen und selber für das Aufräumen sorgen.

    also bei meinem programm hab ich mehrere städte die Gebäude haben .. dabei kann das bsp. das Gebäude "bank" und "Uni" in Stadt "Mannheim" also auch in Stadt "Frankfurt" sein.. es sind die gleichen wenn auch nicht dieselben 😉
    d.h. es gibt sowohl eine Bank in Frankfurt alsauch eine "Bank" in Mannheim.
    Ich erzeuge ein Gebäudeobjekt und tu es in die Building*Liste der betreffenden Stadt. Ne stadt soll eben mehrere gebäude(Bank, Uni, Markt usw..) haben die ich in einer liste abspeichern und aufrufen muss. oh man iss sau kompliziert 😉 ..



  • Braunstein schrieb:

    Ja sicher. Nur warum?
    Bei Zeigern muß er halt immer Gültigkeit prüfen und selber für das Aufräumen sorgen.

    Weil Building abstrakt ist, zudem kann er ja auch smart Pointer benutzen.



  • KasF schrieb:

    Braunstein schrieb:

    Ja sicher. Nur warum?
    Bei Zeigern muß er halt immer Gültigkeit prüfen und selber für das Aufräumen sorgen.

    Weil Building abstrakt ist, zudem kann er ja auch smart Pointer benutzen.

    nee kann ich nicht 😉 k.a. *g



  • Stimmt, das mit dem abstrakt hatte ich irgendwie übersehen. Also Pointer. 🙂



  • bei beiden klassen muss ich noch vorwärts deklarieren oder?
    also

    class Building;
    Class Town
    {..
    }
    

    und umgekehrt in der anderen klasse auch



  • Ja, wenn du in Building den Pointer auf Town halten willst schon.


Anmelden zum Antworten