Verwirrung mit override/overload bei Constructoren

[SirThornberry]

mit overload sagst du dem compiler einfach nur das es zwei methoden mit gleichem Namen gibt. Mit override überschreibst du eben die Methode aus der Klasse von der deine Klasse erbt. Wenn also jemand deine klasse auf die Vorgängerklasse castet und die Methode aufruft wird trotzdem deine neue Aufgerufen (trotz des casts) weil du sie eben überschrieben hast.

Und verdecken heißt einfach das du eine Methode nicht überschreibst diese dann aber nicht mehr aufrufbar ist außer man castet auf dein vorfahren wo noch nichts verdeckt ist.

@robert: in dem Fall scheint es mir dann auch mehr als sinnvoll so vorzugehen wie du es beschrieben hast.

[shmia]

Alle Klassen, die von TComponent abgeleitet wurden, haben einen virtuellen Konstruktor.
Dieser Konstruktor MUSS benützt werden, oder alles "geht in die Hosen".
Siehe Betrag #4 !!

[hsg]

Zitat von shmia:

Alle Klassen, die von TComponent abgeleitet wurden, haben einen virtuellen Konstruktor.
Dieser Konstruktor MUSS benützt werden, oder alles "geht in die Hosen".
Siehe Betrag #4 !!

Er wird ja auch aufgerufen. Von daher ist alles im grünen Bereich.

Zitat von SirThornberry:

mit overload sagst du dem compiler einfach nur das es zwei methoden mit gleichem Namen gibt. Mit override überschreibst du eben die Methode aus der Klasse von der deine Klasse erbt. Wenn also jemand deine klasse auf die Vorgängerklasse castet und die Methode aufruft wird trotzdem deine neue Aufgerufen (trotz des casts) weil du sie eben überschrieben hast.

Und verdecken heißt einfach das du eine Methode nicht überschreibst diese dann aber nicht mehr aufrufbar ist außer man castet auf dein vorfahren wo noch nichts verdeckt ist.

@robert: in dem Fall scheint es mir dann auch mehr als sinnvoll so vorzugehen wie du es beschrieben hast.

Also halten wir fest: overload sagt nicht, dass die Methode verdeckt wird, sondern diese Information bezieht der Compiler aus dem nicht vorhandenen override. Richtig?
Dann hat das alles auch Sinn.
Und nach einer erfrischenden Nacht, verstehe ich auch mittlerweile wieder was ich da mal programmiert habe

Zitat von Robert Marquardt:

Man sollte mehrere Konstruktoren vermeiden. Man verliert dabei naemlich die Kompatibilitaet zum C++ Builder.
es gibt allerdings doch einige lustige Anwendungsmoeglichkeiten wie einen privaten Konstruktor. Man leitet den normalen Konstruktor ab und wirft im Konstruktor eine Exception. Damit wird der normale Konstruktor unbenutzbar. Create ist bei TObject naemlich public und die Sichtbarkeit wird man nicht mehr los. Nun kann man einen privaten Konstruktor implementieren: Somit ist es unmoeglich Objekte dieser Klasse in anderen Units zu instantiieren. Man braucht dann natuerlich eine Factory-Klasse in der gleichen Unit die das uebernimmt.

Wieso verliert man die Kompatibilität zum C++-Builder? Gerade in C++ hat man doch die Möglichkeit der mehreren Konstruktoren, von daher habe ich ja auch diese Programmierweise.
Aber die Idee mit der Exception im Default-Konstruktor gefällt mir.... muss ich mir merken.
Und es ist klar, dass man solche Sachen nicht für Komponenten verwendet.

Danke für die Diskussion.

[Robert Marquardt]

Bei C++ hat man nur genau einen Konstruktor. Delphi macht da ein paar Tricks die Konstruktoren doch abzubilden, aber es laesst sich nicht vollstaendig abbilden. Nicht immer aber gelegentlich laesst sich dann eine Komponente nicht im C++ Builder benutzen.

[hsg]

Zitat von Robert Marquardt:

Bei C++ hat man nur genau einen Konstruktor. Delphi macht da ein paar Tricks die Konstruktoren doch abzubilden, aber es laesst sich nicht vollstaendig abbilden. Nicht immer aber gelegentlich laesst sich dann eine Komponente nicht im C++ Builder benutzen.

Nun verwirrst du mich sehr: Ein Beispiel:

Code:

class Auto
{
private:

  int    AnzahlRaeder;
  double Motorleistung;

public:

  // Defaultkonstruktor:
  Auto()
  {
    Motorleistung = 0.0;
    AnzahlRaeder = 4;
  }

  // überladener Konstruktor:
  Auto( double LeistungKW, int nRad = 4 )
  {
    Motorleistung = LeistungKW;
    AnzahlRaeder = nRad;
  }

};

sind doch zwei Konstruktoren, oder nicht? Und dies sind Beispiele aus Büchern, die keinerlei Bezug auf den C++-Builder haben.
Du hast in C++ genau einen Default-Konstruktor, da gebe ich dir recht. Wenn du ein überschreibenden Konstruktor erstellst, dann musst du auch den Default-Konstruktor definieren.
Aber du hast mehrere Konstruktoren.

Wo ich dir recht gebe, ist der Frust mit der VCL im C++-Builder, da die VCL auch im C++-Builder in Delphi geschrieben ist, sind gerade in der Komponentenentwicklung ein paar krampfige Fingerbruch-Übungen zu machen. Es kann sein, dass da auch was mit Konstruktoren zu Berücksichtigen gab, dazu arbeite ich schon wieder zu lange nicht mehr mit dem C++-Builder.


BTW: ein Vorschlag für DP07: Code-Tag für c++ wäre nett.......