Klassenvererbung mit einer Klasse in einer Klasse.

[EXTEЯNAL]

Moin, habe mal kurz eine Frage, ich versuche grad folgendes zu Realisieren:

MeinKlasse->Auto.Reifen()

Im Konstruktor von MeineKlasse() wird folgendes zugewiesen: m_iSeriennummer.

Ich würde gerne in der Auto.Reifen funktion auf dieser Variable zugreifen können, leider weiß ich nicht wie, ich will keine Zweite Variable extra im Auto Konstruktor dafür anlegen, dass muss auch ohne zweiter Variable klappen (hoffe ich).

So stelle ich mir das ganze ungefähr vor, funktioniert aber natürlich nicht, ich weiß nicht wie ich es sonst beschreiben soll, hoffe ihr versteht mein Problem ...

PHP Code:

class CAuto
{
public:
    class cAuto
    {
    public:
        int Reifen()
        {
            // Code ...
            return this->m_iSeriennummer;
        }
    } Auto;
};

class CMeinKlasse : public CAuto
{
public:
    CMeineKlasse() : m_iSeriennummer(Seriennummer) { }
private:
    int m_iSeriennummer;
    // ...
}; 


[snow]

class CAuto
{

	int m_iSeriennummer;
public:

	CAuto(int Seriennummer = 0) : m_iSeriennummer(Seriennummer) { };

	int Reifen()
	{
		return this->m_iSeriennummer;
	};

};

class CMeineKlasse : public CAuto
{

public:
	CMeineKlasse(int Seriennummer = 0) : CAuto(Seriennummer) { };
};

Das sollte passen. Du erbst ja die Eigenschaften von CAuto, CAuto weiß aber nichts von CMeineKlasse, darum brauchst du die Variable in der CAuto-Klasse. Im Konstruktor wird dann einfach der Konstruktor von CAuto aufgerufen und da der Wert gespeichert.

[EXTEЯNAL]

Ja, dann würde der Aufruf wie folgt aussehen:

CMeineKlasse->Reifen(), dass sollte aber Spererat in einer zweiten Klasse sein, ich möchte nämlich eine DirectX Klasse erstellen.

DirectX->CreateDevice() etc pp ....

Dort in dieser Klasse will ich dann den Device Pointer (DirectX Klasse) als Member speichern, ebenfalls möchte ich in der DirectX Klasse eine zweite Draw Klasse haben die ich wie folgt aufrufe:

DirectX->Draw.Line(...)

Jede Funktion in der Draw Klasse benötigt diesen Device Pointer um überhaupt zu zeichnen.

Gruß

[マルコ]

Dann mach 2 Klassen und in der einen Klasse speicherst du ein Objekt der 2. Klasse. per Getter kannst das dann verwenden...

class CFoo
{
public:

  void doSumthin();
  // ...


};

class CBar
{
public:

  CFoo getFoo() { return pFoo; }
  // ...


private:

  CFoo pFoo;


};

void main()
{

  // ...

  std::unique_ptr<CBar> pBar(new CBar());  // Smart Pointer for easy memory management ;P
  // ...

  pBar->getFoo().doSumthin();
  //...

}

[EXTEЯNAL]

PHP Code:

class CDraw
{
public:
    CDraw(int iDevice) : m_iDevice(iDevice) {}
    ~CDraw() {}
    void Line() {}
    void Box() {}
    void Text() {}
    void Circle() {}
private:
    int m_iDevice;
};

class CDirectX
{
public:
    CDirectX(int iDevice) : m_iDevice(iDevice), Draw(iDevice) {}
    ~CDirectX() {}
    CDraw Draw;
private:
    int m_iDevice;
protected:

};

int main()
{
    CDirectX *Dx = new CDirectX(1337);
    Dx->Draw.Box();
    delete Dx;
    getchar();
    return 1;
} 


Habs nun so, kann man da noch iwas optimieren oder ist dort alles im Grünen Bereich?

Wird der reservierte Speicher der Klasse Box (In CDirectX -> CDraw Draw) eigentlich beim löschen des DirectX Objektes auch gelöscht bzw freigegeben? oder muss ich hier manuell Hand anlegen?

[マルコ]

Variablen niemals als Public setzen. Das hat verschiedene Gründe.

Hier ein paar Beispiele:

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
Hiding the internal representation of the property while exposing a property using an alternative representation.
Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without effecting existing consumers.
Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
Allowing the getter/setter to be passed around as lambda expressions rather than values.
Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.

von

[EXTEЯNAL]

Stimmt schon, kenne diese Regel auch, habe es jetzt nicht bei der Klasse beachtet, dachte es wäre erlaubt für klassen, hab wohl was durcheinander geworfen, danke für den Hinweis, dass mit den Gettern und Settern kenne ich auch.

PHP Code:

int zahl;
int GetZahl() { return zahl } // Gleiches gillt für SetZahl. 


Wie sollte ich das denn für die Klasse benutzen?

PHP Code:

class CDraw
{
public:
    CDraw(int iDevice) : m_iDevice(iDevice) {}
    ~CDraw() {}
    void Line() {}
    void Box() {}
    void Text() {}
    void Circle() {}
private:
    int m_iDevice;
};

class CDirectX
{
public:
    CDirectX(int iDevice) : m_iDevice(iDevice), m_CDraw(iDevice) {}
    ~CDirectX() {}
    CDraw Draw() { return m_CDraw; }

private:
    CDraw m_CDraw;
    int m_iDevice;
protected:

};

int main()
{
    CDirectX *Dx = new CDirectX(1337);
    Dx->Draw().Line();
    getchar();
    return 1;
} 


Sollte so meines Wissen nach richtig sein, falls nicht bitte drauf aufmerksam machen.

Zurück zur Frage, wie sieht es mit der Speicherbereining aus wenn ich die Hauptklasse CDirectX lösche, wird der reservierte speicher für m_CDraw und Draw auch gelöscht?

[マルコ]

Wenn es ein Object ist, wird es beim "Sterben" des Elternobjects auch vernichtet. Wenn es ein Pointer ist, entsteht ein Memory Leak. Du musst Pointer immer freigeben - dazu nimmt man z.B. den Destruktor - oder Smart Pointers^^

[EXTEЯNAL]

Also so wie ich es gelernt habe, sollte man ein Pointer mit delete löschen, sollte eigentlich reichen oder? ^^

Klasse *klasse = new Klasse()
delete klasse; // ruft den Destruktor auf? im right?

[snow]

Schau dir mal Smart Pointer an, die übernehmen das für dich & du musst dicht mehr um delete kümmern. Beim unique_ptr kann nur der unique_ptr auf das Objekt zeigen, beim shared_ptr läuft das ganze über Reference Counting und mehrere Zeiger können auf das selbe Objekt zeigen.
Bei beiden Smart Pointer Typen wird am Ende des Gültigkeitsbereichs bzw. wenn es keine Referenzen mehr auf den Speicher gibt, der Speicher freigegeben.
Was machst du bei delete, wenn vorher eine Exception die Funktion terminiert?

Und ja, delete klasse dürfte den Destruktor aufrufen.

[Hiris]

Warum das Object überhaupt dynamisch im Heap / mit Pointer erstellen? Ist in dem Zusammenhang doch absolut unnötig. Wenn das Objekt nicht dynamisch erstellt wurde wird es automatisch destruktoriert (wenn es das wort gibt :/ ) wenn es den gültigkeits bereich verlässt, also alles easy peasy...

[Padmak]

Zerstört?

Padmak

[Hiris]

Originally Posted by Padmak

Zerstört?

Padmak

destruktoriert hört sich besser an

[Schlüsselbein]

Wie schon gesagt wurde, ist es hier nicht nötig, das Objekt dynamisch zu erzeugen.
Einfach mal als Daumenregel: Wann immer es möglich ist sollten Objekte auf den Stack angelegt werden.
Falls man dennoch ein dynamisch erzeugtes Objekt braucht: RAII.

[LcPlayer1]

Du solltest noch etwas auf die Coding Conventions achten. Funktionen beginnen in der Regel mit einem kleinen Buchstaben.