3. Problem mit #include

Problem mit #include

  • L

    Und die Parameterübergabe geht nicht per Value, mach call-by-reference draus.
    Alternative zu den Pointern als Member sind natürlich Referenzen.

    0
  • D

    unskilled: 0, drakon: 1. :p *SCNR*

    Ok. Vielleicht nur 0.5 für mich, aber mein Artikel sollte bei vernünftigem lesen den Fehler klar machen.

    0
  • F

    Danke für die Tipps.
    Ich les ihn mir nochmal durch:D
    Ja sorry ich weiß war kein Minimalbeispiel 😃

    Gruß freeG

    EDIT:
    Mh aber da ich ja in beiden Klassen auch Objekte der anderen Header-Datei benötige, benötige ich ja die ganze Definition, aber das geht ja wiederum nicht...
    Verstehs grad echt net=(?

    Und nochmal die allgemeine Frage, ist es sinnvoller die Klassen so wie ich jetzt in eine Header-Datei zu packen und eine Source-Datei oder für jede Klasse ne eigene?

    Danke gruß freeG

    0
  • D

    Der Trick ist, dass du im Header nichts hast, was eine Definition verlangt. Wenn du so einen zyklische Abhängigkeit hast, dann musst du halt bei der einten Klasse einen Zeiger auf die andere Speichern (am besten nimmst du dafür einen Smart Pointer, damit du dennoch ein korrektes Verhalten hast beim zerstören).

    Bei Trennung kommt es drauf an. Die meisten halten es so, dass sie eine Klasse in in je einen Header und eine Soruce Datei aufteilen. Mache ich generell auch so, wenn auch mit Ausnahmen (für kleine Hilfsobjekte, oder bei verwandten Klassen).

    0
  • T

    ...

    0
  • F

    Ok sprich ich muss das Design so ändern, dass es Zeiger benutzt.

    Finds blos komisch da das ganze aus nem Buch ist.

    Gut wenn ich alles in eine Header packe müsst es ja gehen...war warscheinlich im Buch so gedacht.

    Gruß freeG

    0
  • ?

    fr33g schrieb:

    Gut wenn ich alles in eine Header packe müsst es ja gehen...war warscheinlich im Buch so gedacht.

    Ohne Zeiger geht das auch nicht, da VOR dem Verwenden der Typ komplett bekannt sein muss - und wie willst du bei zwei Klassen beide vor der jeweils anderen definieren? 😃

    0
  • U

    drakon schrieb:

    [unskilled 0, drakon 1]

    joa 😞 .

    drakon schrieb:

    Der Trick ist, dass du im Header nichts hast, was eine Definition verlangt. Wenn du so einen zyklische Abhängigkeit hast, dann musst du halt bei der einten Klasse einen Zeiger auf die andere Speichern (am besten nimmst du dafür einen Smart Pointer, damit du dennoch ein korrektes Verhalten hast beim zerstören).

    Hm?
    Muss (für das Zerstören) nicht die Definition doch bekannt sein?
    imho sollte das hier nicht gehen:

    class b;

class a
{
 boost::scoped_ptr<b> b_;
};

class b
{
  int x;
};

    oder verwechsel ich da gerade was?

    bb

    0
  • B

    Wenn du statt scoped_ptr einen shared_ptr nimmst, dann geht auch das.

    0
  • F

    So, habs jetzt hinbekommen, dank Eurer Hilfe.
    Hab erst mal das mit Deklaration und Definition beachtet und dann Zeiger in den Klassen verwendet.

    Also vielen Dank nochmal.

    Gruß freeG

    0
  • D

    unskilled schrieb:

    drakon schrieb:

    Der Trick ist, dass du im Header nichts hast, was eine Definition verlangt. Wenn du so einen zyklische Abhängigkeit hast, dann musst du halt bei der einten Klasse einen Zeiger auf die andere Speichern (am besten nimmst du dafür einen Smart Pointer, damit du dennoch ein korrektes Verhalten hast beim zerstören).

    Hm?
    Muss (für das Zerstören) nicht die Definition doch bekannt sein?

    Ich bin mir nicht sicher, ob ich dich richtig verstehe, aber die Zerstörung findet ja im Destruktor statt und der liegt dann einfach nicht im Header, sondern in der .cpp und dort kannst/musst du natürlich die Definition einbinden.

    0
  • U

    drakon schrieb:

    Ich bin mir nicht sicher, ob ich dich richtig verstehe, aber die Zerstörung findet ja im Destruktor statt und der liegt dann einfach nicht im Header, sondern in der .cpp und dort kannst/musst du natürlich die Definition einbinden.

    Nein, vermutlich nicht.
    Ich dachte, mir eingebildet zu haben, dass bei der ersten Instanzierung eines smart-ptrs schon der Destruktor definiert sein muss, damit es richtig zerstört werden kann(da sonst nicht der richtige DTor aufgerufen wird, deshalb auch das checked-delete im SmartPtr-DTor).
    Allerdings hat Braunstein das wohl schon beantwortet - auch, wenn ich den Grund davon nicht verstehe...

    bb

    0
Anmelden zum Antworten