von std::vector erben??

Mario Sandler

Naja, private-Vererbung ist eigentlich keine Vererbung sondern eine Komposition.
D.h. deine Klasse ist nacher kein STL-Container, sondern sie hat einen STL-Container!
Durch den fehlenden virtuellen Destruktor handelst du dir in diesem Fall nur Probleme ein wenn du die Klasse z.B. über den Zeiger der Basisklasse löschen tust.
Dann wird eben der falsche Destruktor aufgerufen. Darum vermeide das Problem indem du private-Vererbung benutzt und die Schnittstelle gezielt freigibst.

Okay das habe ich mitgenommen.

Der Wert von size() nach dem Erstellen des Objektes ist aber immernoch sehr hoch und falsch... :|

camper

jghj schrieb:

Ein Breakpoint nach beiden Objektinitialisierungen im Debugger mit folgenden Outputs von [Objekt].size();

ar.size() = 3958981726
vAr.size() = 0

Ich hab zwar keine Ahnung, was dein Debugger hier anstellt, aber das Ganze ist ohnehin unsinnig. Die size-Memberfunktion muss in deinem Beispiel gar nicht instantiiert werden - der Versuch sie aufzurufen (ist das überhaupt das, was der Debugger dort tut?) daher sinnfrei. Das Verhalten eines Programms ist nicht für Debuggerausgaben definiert worden - wenn die "Größe" des Vektors gar nicht beobachtbar ist, ist die Analyse von Debuggerausgaben sinnlos, wenn du dich nicht von vornherein auf Compilerinterna festlegen willst.

Konrad Rudolph

jghj schrieb:

Dass C++ sehr vielseitig usw. ist und auf Altlasten aufbaut ist mir bewusst, jedoch weiß ich nicht warum ich statt einer Komposition oder anderen OO Vorgehensweisen auf einmal zurück zu C soll und mir Hilfsfunktionen anlegen soll?

Das ist keine Altlast und das hat *nichts* mit C zu tun. Es ist vielmehr ein anderes Paradigma. OOP ist auch *nicht* das Heilige Gral. Diese Hilfsfunktionen sind klares, elegantes und modernes algorithmenbasiertes Anwendungsdesign.

Artchi

Die Algorithmen lassen sich auf (fast) alle Container anwenden, ohne das es eine Basisklasse geben muß. Das Design ist bewusst so gewählt und ich wette, man würde es heute nochmal so machen. Vielleicht würde es heute Detailsänderungen geben, aber das Paradigma würde heute genauso umgesetzt werden. Man muß das Zeug halt verstehen, dann wird man nicht sagen, das es Altlast ist.

camper schrieb:

jghj schrieb:

Ein Breakpoint nach beiden Objektinitialisierungen im Debugger mit folgenden Outputs von [Objekt].size();

ar.size() = 3958981726
vAr.size() = 0

Ich hab zwar keine Ahnung, was dein Debugger hier anstellt, aber das Ganze ist ohnehin unsinnig. Die size-Memberfunktion muss in deinem Beispiel gar nicht instantiiert werden - der Versuch sie aufzurufen (ist das überhaupt das, was der Debugger dort tut?) daher sinnfrei. Das Verhalten eines Programms ist nicht für Debuggerausgaben definiert worden - wenn die "Größe" des Vektors gar nicht beobachtbar ist, ist die Analyse von Debuggerausgaben sinnlos, wenn du dich nicht von vornherein auf Compilerinterna festlegen willst.

Ich bin da jetzt zwar nicht ganz mitgekommen aber habe was entdeckt... man gebe die Rückgabe von size() in printf() und er gibt eine 0 zurück.

Woa ... und ich habe gerade alles durchgetestet es funktioniert .... dann hab ich einen Programmfehler wohl an einer komplett falschen Stelle gesucht, weil ich über das Debuggerergebnis stutzig geworden bin, welches bei mir noch nie falsch war!

Wäre garnicht auf die Idee gekommen, dass die Ausgabe eine unterschiedliche sein kann....

Vielen Dank für die schnelle Unterstützung ... wieder was dazugelernt und 2 Tage durch das Suchen an der falschen Ecke vergeuded

Wünsch euch noch einen schönen Sonntag.

mfg jghj

Artchi schrieb:

Die Algorithmen lassen sich auf (fast) alle Container anwenden,...

Von welchen Algorithmen sprichst du? Weißt du von welchen ich gesprochen habe? Außerdem ist das sowas vom Thema ab...willst du dich jetzt rechtfertigen, warum du meine Frage nicht beantworten konntest indem du dich an irgendwelche Normen festbeißt? Deine letzten Beiträge hatten nichts mehr mit meiner Problemlösung sondern viel mehr mit "ich probiere die Kompetenz der anderen in Frage zu stellen" zu tun, wofür ich dir keinen Grund gegeben habe und das meiner Meinung nach auch nicht Zielführend ist.

Lies dir mal durch, wie oft du auf meine Fragen geantwortet hast ohne Bezug. Oder schreibe ich so undeutlich, dass man das falsch verstehen muss??

lg jghj

Konrad Rudolph

jghj schrieb:

Oder schreibe ich so undeutlich, dass man das falsch verstehen muss??

Nein, aber anscheinend schreiben wir so undeutlich, dass Du nicht verstehst.

Das, was Du vorhast, ist in C++ nicht vorgesehen (und aus guten Gründen). Man macht das in C++ einfach anders. Wir empfehlen Dir daher dringend, es ebenfalls so zu machen, denn alle anderen Lösungen haben nunmal massive Nachteile. Abgesehen davon wurden aber bereits verschiedene Ansätze aufgezeigt, die Dein Problem lösen sollten.

Also was willst Du?

finix

jghj schrieb:

Ich will keine Monsterklasse bauen.

Dann habe ich dich wohl missverstanden; ich dachte du wolltest ein Array mit char* -spezifischen Methoden ausstatten.

jghj schrieb:

Und ich denke, dass das Objektorientierte design schon seine Daseinsberechtigung hat. Auch wenn nicht möchte ich es in diesem realisieren und meine eigenen Prozeduren als Methoden und nicht als (globale) Funktionen realisieren.

Wer hier hat denn dem Objektorientiertem Design die Daseinsberechtigung abgesprochen? Wieso meinst du mein Vorschlag sei nicht Objektorientiert? Oder war das OOD schlicht ein Tippfehler und du meinst eigentlich Design rein auf statischen Klassen basierend?

Wieso nutzt du bei deiner Abneigung gegen Funktionen eigentlich die STL?

jghj schrieb:

Dass C++ sehr vielseitig usw. ist und auf Altlasten aufbaut ist mir bewusst, jedoch weiß ich nicht warum ich statt einer Komposition oder anderen OO Vorgehensweisen auf einmal zurück zu C soll und mir Hilfsfunktionen anlegen soll?

Hm. Dass du den Unterschied zwischen globaler und freier Funktion nicht kennst mag man ja noch durchgehen lassen, aber Funktionen als Altlast zu bezeichnen und sie scheinbar abfällig gemeint generell Hilfsfunktionen zu nennen zeugt nicht wirklich von Klasse.

Artchi

jghj schrieb:

Artchi schrieb:

Die Algorithmen lassen sich auf (fast) alle Container anwenden,...

Von welchen Algorithmen sprichst du?

1. den Standard-Algorithmen (sort, find, transform u.a.)
2. jeder fremde Algorithmus der sich an das STL-Paradigma der Std-Lib hält

jghj schrieb:

Weißt du von welchen ich gesprochen habe?

Muß ich nicht wissen, weil es irrelevant ist, wenn ein Algo nach STL-Paradigma implementiert wurde.

jghj schrieb:

willst du dich jetzt rechtfertigen, warum du meine Frage nicht beantworten konntest indem du dich an irgendwelche Normen festbeißt? Deine letzten Beiträge hatten nichts mehr mit meiner Problemlösung sondern viel mehr mit "ich probiere die Kompetenz der anderen in Frage zu stellen" zu tun, wofür ich dir keinen Grund gegeben habe und das meiner Meinung nach auch nicht Zielführend ist.

Nach drei Seiten hast du den Fehler bei dir gefunden, obwohl wir dir sehr früh korrekte Antworten lieferten. Ich habe sogar versucht zu erklären, warum das so und nicht anders ist. Nur werde ich keine umfassende Std-Lib-Aufklärung leisten, die in jedem gescheiten C++-Buch oder -Tutorial erklärt wird. Oder hast du keine C++-Literatur?

Weiterhin habe ich trotzdem sehr wohl Stichworte geliefert, die den Grund dieses Paradigmas nennen. Wenn du dir meine Beiträge nochmal aufmerksam durchliest, wirst du Begriffe wie Templates und Performance vorfinden, die nicht unbedeutend sind (besonders letzteres ist wichtig). Konrad hat auch noch zum Schluss den "algorithmenbasiertes Anwendungsdesign" nachgeliefert, was es nochmal auf den Punkt bringt.

finix

jghj schrieb:

Artchi schrieb:

Die Algorithmen lassen sich auf (fast) alle Container anwenden,...

Von welchen Algorithmen sprichst du?

Zum Beispiel von den Algorithmen der Standardbibliothek. Deine Collectionlib müsste konsequenterweise eigentlich ungefähr so aussehen:

namespace my_oo_stl {
  class vector
  {
  public:
    // adapt std::vector methods

    // object oriented "functions":
    void sort( Ordering o )
    {
      ::std::sort(v.begin(), v.end(), o);
    }

    void for_each( FunctionObject f ) {
      ::std::for_each(v.begin(), v.end(), 
    }

    // etc. ad inf.

  private:
    ::std::vector v;
  };
}