3. statische Member vererben?

statische Member vererben?

  • ?

    Werden statische Member automatisch "mit" vererbt=

    Bsp:

    class Base{
  ...
  protected:
    static string x;
};

class Sub : public Base{
  ...
};

string Sub::x = "Text..."
    0
  • D

    Hi!

    Ja, aber warum versuchst du's nich einfach??? 🙄
    Nur wenn du den Zugriff mit protected oder private spezifizierst hast du halt ein Problem...

    grüße

    0
  • ?

    Ich habe es natürlich schon probiert, aber es funktioniert nicht.
    1:1 wie oben, nur natürlich ohne "..."!

    Was sollten sich für Probleme mit protected ergeben?

    0
  • B

    statiX schrieb:

    Was sollten sich für Probleme mit protected ergeben?

    Wie gut sind denn deine Englischkenntnise? 😃 Ich mein das Wort protected heißt doch schon "geschützt"... 😉 Also ist der Member vom Zugriff von außen geschützt. Nur abgelittene Klassen können auf diesen Member zugreifen.

    0
  • ?

    Na und? Will ich von außen zugreifen? - Nein!
    Und ja, es macht in meinem fall Sinn. Aber leider funktioniert es ja nicht!

    0
  • B

    staticX schrieb:

    Na und? Will ich von außen zugreifen? - Nein!

    Sorry, aber das hab ich in meiner Kristallkugel heute anders gesehen. 😉 [ROFL, wobei ich zugeben muss, dass ich teilweise daran Schuld bin... so spät ist meine Kristallkugel halt ein wenig eingestaubt, da kann man schonmal unscharf sehen]

    Mal abgesehen davon, was bringt den das, wenn du den statischen Member über die abgelittene Klasse definierst? Is doch sowieso statisch...

    0
  • M

    Du musst natürlich

    string Base::x = "text...";

    schreiben.

    0
  • ?

    Michael E. schrieb:

    Du musst natürlich

    string Base::x = "text...";

    schreiben.

    Dann habe ich die Basisklasse initialisiert. Will ich aber nicht. Ich möchte von Base mehrere Klassen ableiten. Alle sollen ihren eigenen String bekommen.

    0
  • B

    Dann solltest du evtl. keinen statischen Member nehmen 😉 Denn gibts nämhlich nur einmal und nicht pro abgelittener Klasse.

    0
  • J

    Dann mußt Du die auch der jeweiligen Klasse hinzufügen.
    Was allen Base-Objekten zusammen gehört kommt in Base. Was unterschiedliche Unterklassen von Base nicht gemeinsam haben sollen kommt auch nicht nach Base.

    0
  • ?

    Also ist die Antwort auf meine Frage nein.
    Unterklassen bekommen nicht eine "eigene" statische Variable. Ok...
    Dann muss eben doch was rein virtuelles a la

    //Base:
virtual string getX(void) = 0;
...
//Sub:
string getX(void) { return "Text..."; }
    0
  • ?

    und @Jester:

    Den String "x" haben alle Unterklassen gemeinsam! Deswegen sollte es ja in Base!

    0
  • O

    staticX schrieb:

    und @Jester:

    Den String "x" haben alle Unterklassen gemeinsam! Deswegen sollte es ja in Base!

    x vielleicht, aber nicht den text der dahinter steht 🙄

    0
  • ?

    Was für Möglichkeiten gäbe es denn, so einen String zu implementieren?

    1.

    class Base{
  static string x; 
}
string Base::x = "Base..."; 

class Sub1 : public Base{
  static string x; 
}
string Sub1::x = "Sub1..."; 

class Sub2 : public Base{
  static string x; 
}
string Sub2::x = "Sub2...";

    2.

    class Base{
  virtual static string getX(void) = 0; 
}

class Sub1 : public Base{
  virtual static string getX(void) {return "Sub1...";} 
}

class Sub2 : public Base{
  virtual static string getX(void) {return "Sub2...";} 
}

    Was für andere gibt es noch?

    0
  • R

    Ne static abstrakte methode ? ^^

    Ohje, glaub klein wenig Nachhilfe in Polymorphie waere ned so schlecht !

    Glaub von der Logic verhaust Du Dich grad maechtig.

    Polymorphie:
    - Der typ einer Instanz wird bei der Erzeugung festgelegt.
    - Alle polymorphen Instanzen erhalten eine VTable (Table der Adressen fuer die virtuellen funktionen)
    - bei der erzeugung (new oder stack oder ...) wird die Vtable mit den adressen der Funktionen der klasse gefuellt, mit der erzeugt wird ....
    - wird eine virtuelle funktion nicht implementiert, wird der der unmittelbaren Basisklasse genommen, wenn der auch nicht, dann wird weiter in der hirachie nach unten gesucht.
    - gibt es gar keine Implementation, kann die vtable nicht erstellt werden, und damit keine Instanz -> abstrakte klasse

    Statische Funktionen:
    - sind globale funktionen die im namensraum der Klasse "versteckt" werden
    - zusaetztlich bekommen sie nur noch die Zugriffsprivilegien der Klassen ab (public,private,protected)
    - funktionieren damit total unabhaengig irgendwelcher Instanzen.
    - abgeleiteten klassen koennen statische funktionen ueberdecken, es funktioniert wie die normale Namensaufloesung bei member funktionen.
    - In der Regel qualifiziert man den Aufruf voll (um konflikte zu vermeiden) mit der Klasse dessen methode man aufrufen will ... also B::x() zum beispiel ...
    - wird der name ned voll qualifiziert, wird der name durch den statischen Typ der variable wo man dran aufruft ergaenzt ...., also B * p1; p1->x(); // es wird B::x() aufgerufen, reinterpret_cast<C*>(p1)->x(); // statische typ des Zeigers nach dem Cast ist C* also wird C::x() aufgerufen.

    also polymorphie und static beissen sich gewaltig ....
    Man kann schon intressante effekte mit erzielen, aber die sind meist nicht wirklich gewollt, oder lassen sich durch andere sachen saueber loesen. und man macht einfach die zuordnung, wann welche funktion aufgerufen wird, verworrener -> schlecht wartbarer Code.

    Also schreib lieber verbal was genau du erreichen willst (da bin ich noch ned so hinterkommen) und vielleicht koennen wir dir dabei helfen es umzusetzen ...

    Ciao ...

    0
  • ?

    Ich habe eine ähnliche Frage hier schon einmal gestellt und verstehe ehrlich einfach nicht was die Leute daran nicht raffen. Ich werde mal noch etwas konkreter mein Problem beschreiben:

    Klar ist static(nur über "die Klasse" ansprechbar) und virtual(tut abhängig vom Typ, der "verlohren" gegangen sein kann(z.B. Basisklassen Pointer auf Objekte von erbenden Klassen), "genau das richtige") ein Widerspruch.
    Die Basis Klasse ist aber aus verschiedenen Gründen bereits pure virtual - Und das ist auch gut so.
    Bei dem String handelt es sich um einen String, der quasi eine kleine Grammatik enthält. Jede Klasse, die sich von Base ableitet implementiert auf andere Weise eine andere Grammatik.
    Ist es nicht verständlich, dass jede Klasse deswegen genau einen String braucht?

    Ich würde hier bei static virtual auch den Vorteil sehen, dass jede Klasse, die sich ableitet - und damit eine Grammatik implementiert - auch wirklich eine Grammatik hat.

    Echt, ich meine das nicht unhöflich, nur frage ich mich wirklich warum alle Leute sofort anfangen "Nachhilfe" zu geben.(Was ja eigentlich sehr nett ist. Ist ja immerhin ein zentrales Thema der Sprache und auch nicht einfach und kurz zu erklären)

    Würdet ihr sagen "...implementiert auf andere Weise eine andere Grammatik..." sagt bereits, dass hier falsch modelliert wurde?

    Also, schreibt einfach was dazu. Mich interessiert die Sache 😉

    gruß an mein lieblings forum 😉

    0
  • L

    Da sowohl Code einer jeden Klasse wie auch statische Felder innerhalb ihrer Methodenrümpfe nur einmal im Speicher vorkommen, wäre eine denkbare Lösung:

    class Basis {
  virtual const string& getX() = 0;
};

class Sub1 {
  virtual const string& getX();
};

const string& Sub1::getX() {
  static string grammar( "eine sub1 grammatik" );
  return grammar;
}

class Sub2 {
  virtual const string& getX();
};

const string& Sub2::getX() { 
  static string grammar( "eine sub2 grammatik" );
  return grammar;
}
    0
  • ?

    Ok, das ist gut. Ist aber ja ähnlich wie ich oben unter 2. geschrieben habe.
    Hätte halt noch den Vorteil, dass der String nur einmal initialisiert wird und dann immer nur zurückgegeben wird.

    0
  • ?

    Ok, keine weiteren Vorschläge?

    0
  • Z

    staticX schrieb:

    Ok, keine weiteren Vorschläge?

    Welche Vorschläge willst du denn noch.
    Im Beispiel von LordJaxom hast du für jede Klasse genau einen statischen String der obendrein nur dann initialisiert wird wenn er auch gebraucht wird.
    Kurt

    0
Anmelden zum Antworten