3. implements?

implements?

  • P

    kann vielleicht jmd was zum problem sagen? müssen methoden, die in der vererbenden klasse definiert sind auch in der erbenden klasse definiert oder nur implementiert werden ?

    CStoll schrieb:

    Ist es eigentlich Absicht, daß die Methoden der SDL_Button alle auskommentiert sind? (btw, dieser Quelltext passt absolut nicht zu den Fehlermeldungen)

    äh? welchen quelltext willst du haben ?

    ich hab die auskommentiert, da sie ja schon in Input definiert sind? wieso sollte man sie dann in einer von input erbenden klasse nochmal definieren ?

    edit: nach den "tutorials" müsste das, was ich hier versuche funktionieren

    0
  • ?

    2. kann vielleicht jmd was zum problem sagen? müssen methoden, die in der vererbenden klasse definiert sind auch in der erbenden klasse definiert oder nur implementiert werden ?

    beides, und das ist wichtig. und ich nehm mal an, da du diese frage stellst, ist genau das das problem 😉

    class A
{
  virtual void foo() = 0;
};

class B : public A
{
};

int main() {
  B b;
}

// ...

void B::foo() {
  // irgendwas
}

    das geht durch den compiler, weil B::foo() einfach eine ungebundene methode ist. aber der linker jammert, weil ihm die implementierung von B::foo fehlt (keine deklaration)

    0
  • A

    pixartist schrieb:

    ich hab die auskommentiert, da sie ja schon in Input definiert sind? wieso sollte man sie dann in einer von input erbenden klasse nochmal definieren ?

    Weil man es muss. In Java bemerkst du es nicht, weil du Deklaration und Definition nicht trennst. Grundsätzlich muss alles im Header deklariert werden, was du im Source definierst (okay, gibt Ausnahmen wie das Body-Handle-Idiom [auch pImpl genannt] wo ein Teil der Deklaration erst im Source erfolgt - wer nicht weiß was es ist darf googlen wenn es ihn interessiert).

    Grundsätzlich wird erst der Header beim Compilieren betrachtet, erst danach der Source.

    cu André

    0
  • P

    ~thordk schrieb:

    2. kann vielleicht jmd was zum problem sagen? müssen methoden, die in der vererbenden klasse definiert sind auch in der erbenden klasse definiert oder nur implementiert werden ?

    beides, und das ist wichtig. und ich nehm mal an, da du diese frage stellst, ist genau das das problem 😉

    class A
{
  virtual void foo() = 0;
};

class B : public A
{
};

int main() {
  B b;
}

// ...

void B::foo() {
  // irgendwas
}

    das geht durch den compiler, weil B::foo() einfach eine ungebundene methode ist. aber der linker jammert, weil ihm die implementierung von B::foo fehlt (keine deklaration)

    also wäre richtig:

    class A
{
  virtual void foo() = 0;
};

class B : public A
{
  void foo();
};

int main() {
  B b;
}

// ...

void B::foo() {
  // irgendwas
}
    0
  • A

    Achso weiterer Nachtrag weil ich es hier sehe:

    Etwas das du dir auch versuchen solltest in C++ anzugewöhnen, sind Referenzen bei der übergabe. An vielen Stellen kopierst du beim Aufruf Daten unnötig. Und hierzu noch etwas weiteres: Man sollte möglichst wenig Abhängigkeiten im Header schaffen, und diese lieber in den Source verschieben (Reduziert u.a. Linkzeiten).

    Beispiel:

    ...
class SDL_Input
{
public:
    ...
    virtual void setPos(Vektor v) = 0;
    ...
};
#endif

    Hier gibt es schon mehrere Dinge die ich anmerken will:
    a) Ich habe in deinen Code keine Deklaration von Vektor gefunden, wo inkludierst du den? Die Klasse muß wie du sie hier verwendest jedenfalls im Header bekannt sein.

    b) Mit dem Aufruf von setPos erzeugst du eine Kopie, was sicherlich nicht der Performance zuträglich ist. Um dies zu umgehen sollte man auf Zeiger (wenn es auch null sein darf) oder Referenzen (wenn es nicht null sein darf) ausweichen. Es sei den es ist an der Stelle explizit gewollt das man Kopiert (wobei ich das dann erst im Source machen würde. Wenn ich mich noch richtig erinnere wird in Java hier eine Referenz (bzw. eigentlich ein Zeiger der aber Syntaktisch an eine Referenz erinnert, verwendet).

    Bei C++ musst du Referenzen immer explizit angeben. Wo ist nun der Vorteil von Referenzen / Zeigern zu deiner Übergabe:
    a) Keine Kopie nötig
    b) Eine Einfache Vorwärtsdeklaration im Header (und inklude im Source) reicht, was sich z.B. auf die Compilezeit auswirkt
    c) Man kann mittels const sehr schon angeben was nun manipuliert werden kann und was nicht.

    Beispiel:

    Beispiel:

    ...

class Vektor; // Vorwärtsdeklaration
class SDL_Input
{
public:
    ...
    virtual void setPos(Vektor& v) = 0; // Variante 1
    virtual void setPos(Vektor& const v) = 0; // Variante 2a
    virtual void setPos(const Vektor& v) = 0; // Variante 2b
    virtual void setPos(Vektor const * v) = 0; // Variante 3a
    virtual void setPos(const Vektor* v) = 0; // Variante 3b
    virtual void setPos(Vektor* const v) = 0; // Variante 4
    virtual void setPos(const Vektor* const v) = 0; // Variante 5a
    virtual void setPos(Vektor const * const v) = 0; // Variante 5b
    ...
};
#endif

    Varianten:
    1. Referenz die geändert werden kann
    2a/2b. Konstante Referenz, keine Änderung möglich
    3a/3b. Nicht-Konstanter Zeiger auf konstantes Objekt
    4. Konstanter Zeiger auf nicht konstantes Objekt
    5a/5b. Konstanter Zeiger auf konstantes Objekt

    Ich hoffe jetzt alles richtig wiedergegeben bei 2a bin ich mir grad nicht 100% sicher (Ich verwende eigentlich bei konstanten Referenzen nur 2b). Bei Zeigern halte ich mich an folgende Regel die es erleichtert:

    Schreibe immer const hinter den Teil der Konstant sein soll
    ...methode(typ [const] * [const] name)...

    cu André

    0
  • P

    hm ok, aber wenn ich ein objekt lokal erzeuge, dann einen pointer an ein klassenobjekt übergebe, und das objekt dannach eigentlich gelöscht werden würde(lokal erstellt!), zeigt der pointer dann nicht ins leere ? (der pointer, der im klassenobjekt gespeichert wurde)

    0
  • A

    pixartist schrieb:

    hm ok, aber wenn ich ein objekt lokal erzeuge, dann einen pointer an ein klassenobjekt übergebe, und das objekt dannach eigentlich gelöscht werden würde(lokal erstellt!), zeigt der pointer dann nicht ins leere ? (der pointer, der im klassenobjekt gespeichert wurde)

    Ja, der Zeigt dann ins Leere. Aber Pointer würde ich eh nur verwenden wenn eine null-Übergabe zulässig sein soll (ansonsten ist die Referenzübergabe immer orzuziehen) - Kopieren kannst du den Wert auch in der aufgerufenen Methode noch. Bei der Pointerübergabe ist immer auf die Objektherrschaft zu achten (in der Regel benutzt man Pointer mit new/delete zusammen).

    Eine Alternative zum klassischen Pointer sind intelligente Smartpointer (z.b. boost::shared_ptr), siehe auch http://www.boost.org/libs/smart_ptr/smart_ptr.htm ).

    cu André

    0
  • C

    Zu den Referenz-Varianten: 2a ist Käse, das wäre eine konstante Referenz auf ein veränderbares Objekt (analog zu Variante 4) - aber da Referenzen sowieso konstant sind, ist so eine Angabe sinnlos. Richtig wäre Vektor const& v - und das ist wirklich äquivalent zu 2b.
    (du kannst dir merken: alles vor dem &/* bezieht sich auf das Ziel, alles danach auf die Referenz/Zeiger selber)

    0
  • P

    CStoll schrieb:

    Zu den Referenz-Varianten: 2a ist Käse, das wäre eine konstante Referenz auf ein veränderbares Objekt (analog zu Variante 4) - aber da Referenzen sowieso konstant sind, ist so eine Angabe sinnlos. Richtig wäre Vektor const& v - und das ist wirklich äquivalent zu 2b.
    (du kannst dir merken: alles vor dem &/* bezieht sich auf das Ziel, alles danach auf die Referenz/Zeiger selber)

    ok, sry das ich so dumm frage, aber ich bin grad etwas verwirrt!?

    void methode(klasse *test)

    hier bekommt die methode eine variable, die eine adresse enthält, wobei an dieser adresse ein objekt vom typ klasse liegt.

    void methode (klasse &test) (bzw const& test)
    was enthält test jetzt?

    0
  • C

    pixartist schrieb:

    void methode (klasse &test) (bzw const& test)
    was enthält test jetzt?

    Ist doch ganz einfach: Eine Referenz (Alias-Name) auf ein 'klasse'-Objekt.

    (wenn du es primitv betrachten willst, ist eine Referenz etwas ähnliches wie ein konstanter Zeiger, der sich bei der Verwendung automatisch dereferenziert - und häufig wird der Compiler sie auch genau so umsetzen)

    0
  • P

    CStoll schrieb:

    pixartist schrieb:

    void methode (klasse &test) (bzw const& test)
    was enthält test jetzt?

    Ist doch ganz einfach: Eine Referenz (Alias-Name) auf ein 'klasse'-Objekt.

    (wenn du es primitv betrachten willst, ist eine Referenz etwas ähnliches wie ein konstanter Zeiger, der sich bei der Verwendung automatisch dereferenziert - und häufig wird der Compiler sie auch genau so umsetzen)

    und was passiert jetzt wenn ich das übergebene objekt lokal erstellt hab ?

    0
  • C

    Du meinst so?

    void function(int& test)
{
  test+=10;
}

void test_function()
{
  int i=5;
  function(i);
}

    Aus Sicht von function() ist es egal, wo das übergebene Objekt liegt - die Referenz ist bei diesem Aufruf ein anderer Name von test_function()::i, also wird der Aufruf auch dessen Wert verändern.

    0
  • L

    pixartist schrieb:

    und was passiert jetzt wenn ich das übergebene objekt lokal erstellt hab ?

    Was soll passieren? Du greifst in der aufgerufenen Funktion auf das in der aufrufenden Funktion lokal erstellte Objekt zu.

    0
  • P

    nein, ich meine wenn ich das objekt, welches ich lokal erstelle und an die methode in form einer referenz übergebe, in der klasse in einer klassenvariable speichern will. darum gings doch schon 3 posts weiter oben

    0
  • C

    Wenn du das Objekt in eine Klassenvariable (die natürlich kein Zeiger sein sollte) speicherst, wird es dabei natürlich kopiert. Wenn du einen Zeiger auf die Adresse des lokal erzeugten Objekts speicherst, zeigt der natürlicherweise ins Nirvana (und du hast keine Möglichkeit, sowas zu erkennen ⚠ ).

    0
  • P

    CStoll schrieb:

    Wenn du das Objekt in eine Klassenvariable (die natürlich kein Zeiger sein sollte) speicherst, wird es dabei natürlich kopiert. Wenn du einen Zeiger auf die Adresse des lokal erzeugten Objekts speicherst, zeigt der natürlicherweise ins Nirvana (und du hast keine Möglichkeit, sowas zu erkennen ⚠ ).

    arghhh aber wie in aller welt soll es dann möglich sein, verschiedene objekte in einem klassenobjekt zu speichern, die von einer klasse erben? mein plan sah so aus:

    ich habe eine klasse "panel" oder so, und verschiedene input typen, zb. textEdit, button, dropdown usw, die alle von der klasse SDL_Input erben. nun will ich solch einem panel verschiedene inputs übergeben, die dann nurnoch in dem objekt gespeichert sind und davon verwaltet werden (panel)
    das muss doch irgendwie möglich sein?!

    das problem ist, das ich die verschiedenen input typen alle in EINER liste speichern will, damit ich mir falls benötigt neue input typen erstellen kann, ohne die panel klasse anzurühren

    0
  • C

    Sowas geht normalerweise nur über Pointer (ja, in manchen Situationen stoßen Referenzen an ihre Grenzen). Und dabei mußt du dann dafür sorgen, daß die verpointerten Objekte lange genug überleben.

    (eventuell sind dafür auch Smart-Pointer wie std::auto_ptr oder boost::shared_ptr verwendbar)

    0
  • K

    hab ich doch im Anfang auch gesagt, du must die Liste anstatt mir den Daten direkt mit pointern der Basisklasse erstellen, dann kannst du auf diesen auch adressen der abgeleiteten klassen speichern. Du kannst auf die Methoden der Abgeleiteten klassen nur zugreifen, wenn sie auch in der Basisklasse existieren, und dort virtual sind.

    0
Anmelden zum Antworten