3. Vererbung

Vererbung

  • W

    daersc schrieb:

    Wenn du den Konstruktor selbst deklartierst, wird ihn der Compiler nicht selbst erzeugen und das tun, was du willst.

    Aber wie muß der Konstruktor aussehen? Nur a übergeben bringt ja nicht so viel.

    class A {
public:
	int i;
};

class B : public A {

public:
	B (A *a) {
            // ???????
	}
};

int main() {

	A *a = new A();
	a->i = 5;

	B *b = new B(a);
	cout << b->i << endl; //gibt 0 aus.
}
    0
  • W

    ... schrieb:

    Ein B ist doch ein A. Überall wo ein A erwartet wird kannst Du ein B nehmen.

    Ich habe ein a, will es aber um die Eigenschaften von b erweitern.

    0
  • J

    WonkoTheSane schrieb:

    Aber wie muß der Konstruktor aussehen?

    Als Parameter eine const-Referenz und dann den Basis-Ctor aufrufen, also so:

    B(const A& a) : A(a)
// hier B-Krams initialisieren
{}
    0

  • WonkoTheSane schrieb aber, daß er das Objekt a nicht kopieren möchte... und das geht eben nicht!
    Denn das neu erzeugte Objekt b besteht ja intern aus dem dazugehörigen Speicher für die Basisklasse A und dahinter (oder davor - auf jeden Fall aber am Stück!) aus dem Spicher für die Member von B.
    Nun kann aber nachträglich nicht einfach der Speicher hinter dem Objekt a einfach überschrieben werden, da dieser ja evtl. zu einem anderen Objekt schon gehört.

    Wenn der Kopieraufwand für das Objekt a zu groß ist (bzw. sogar unkopierbar), dann kann man ja einfach eine Referenz oder einen Zeiger in der Klasse B dafür anlegen (dann aber nicht mehr von A ableiten!).

    0
  • N

    Th69 schrieb:

    Wenn der Kopieraufwand für das Objekt a zu groß ist (bzw. sogar unkopierbar), dann kann man ja einfach eine Referenz oder einen Zeiger in der Klasse B dafür anlegen (dann aber nicht mehr von A ableiten!).

    Meinem Eindruck nach wäre das ohnehin sinnvoll. Keine Vererbung, und dafür Aggregation.

    @ WonkoTheSane:
    Wieso möchtest du ein B von einem A konstruieren?

    0
  • W

    @Th69: OK, das mit der Speicherverwaltung leuchtet mir ein.

    Nexus schrieb:

    Wieso möchtest du ein B von einem A konstruieren?

    Z.B. arbeite ich mit dem Qt-Framework. Für den Datenbankzugriff gibt es ein QSqlTableModel. Das repräsentiert die Tabelle. Eine Zeile wird durch einen QSqlRecord repräsentiert.

    Mit

    tableModel.record(0).fieldName("id")

    greife ich auf die Spalte "id" in der ersten Zeile zu.

    Meine Idee war, ein typisiertes TableModel mit einem typisierten QSqlRecord abzuleiten, so dass ich den Spaltennamen nicht als String angeben muss.

    Also:

    tableModel.record(0).id

    So würden falsche Feldnamen schon beim compilieren auffallen. Ich bin nicht sicher, ob es eine gute Idee ist, wenn ich dazu jeden QSqlRecord kopieren muss. Besonders wenn man sie zur Verarbeitung in einer Schleife durchläuft.

    0
  • W

    Du könntest vllt von QSqlTableModel ableiten welches spezialierte/typisierte QSqlRecord liefert. Hört sich aber nach einer Menge Schreibarbeit an.

    0
  • W

    witte schrieb:

    Du könntest vllt von QSqlTableModel ableiten welches spezialierte/typisierte QSqlRecord liefert. Hört sich aber nach einer Menge Schreibarbeit an.

    In der abgeleiteten Klasse muss ich dazu aber immer noch aus dem QSqlRecord einen typisierten machen.

    Die Schreibarbeit könnte man automatisieren. 🙂

    0
  • W

    WonkoTheSane schrieb:

    In der abgeleiteten Klasse muss ich dazu aber immer noch aus dem QSqlRecord einen typisierten machen.

    Nein, die abgleitete QSqlTableModel soll gleich abgeleitete QSqlRecord liefern.

    0
  • W

    witte schrieb:

    Nein, die abgleitete QSqlTableModel soll gleich abgeleitete QSqlRecord liefern.

    Hmm. Irgendwie stehe ich auf dem Schlauch. Wie soll das denn gehen? Ich habe doch nur die QSqlRecords aus der Basisklasse.

    So sieht das aus:
    http://doc.trolltech.com/4.6/qsqltablemodel-members.html

    (siehe record ( int ) const : QSqlRecord )

    0
Anmelden zum Antworten