ich hab jetzt eine Abstrakte Klasse Hash. Diese hat unter anderem eine rein virtuelle Methoden HashLength. Diese moechte ich jetzt im Konstruktor verwenden um mit new Platz fuer den Hash zu reservieren. Kommt aber immer unresolved external.
Also prinzipiel versteh ich schon warum das ned geht, weil er ja versucht die Methode Hash::HashLength aufzurufen. Aber ich habe mir gedacht da es ja sowieso eine abstrakte Klasse ist und dies eine rein virtuele Methode ist geht das da ich die ja in der abgeleiteten Klasse impelementiere. Ich hab mir jetzt so geholfen das ich nen Konstruktor mit der Size als uebergabe Parameter hab fuer Hash.

Jetzt ist die Frage ob das mit der Methode einfach nicht geht oder ob ich was anders machen muss.

Gruess C0de4Fun

[...]

Bitte was? Was für einen Widerspruch? Bitte keine zusammen gereimte Verallgemeinerungen. Konkrete Beispiele.

1. C++ und RAII passen gut zusammen (vgl. Stroustrup)
2. Bei einem Fehler soll eine Ausnahme geworfen werden

Als man std::file entwarf, gab es beide Prämissen noch nicht in dieser Form, daher sind sie erst nachträglich hinzuimplementiert worden. Ich kritisiere aber noch nicht die veraltete Standardbibliothek (kommt unten), sondern betrachte als Beispiel eine file -Klasse in modernem C++.

Aus 1. folgt: Konstruktor öffnet die Datei, Destruktor schliesst die Datei.
Aus 2. folgt: Bei irgend einem Fehler beim Öffnen/Schliessen der Datei wird eine exception geworfen.
Schlussfolgerung: Der Destruktor muss manchmal eine Ausnahme werfen.

Dass das nicht geht ist dir hoffentlich klar. Ich gehe einen Schritt weiter:

fdfdg schrieb:

man kann auf Destruktionsfehler eben oft schlecht reagieren.

Das ist so, da kann C++ direkt nichts dafür.
Der Widerspruch liegt in den Prämissen zugrunde, d.h 1 und 2 sind zueinander widersprüchlich. Ist der Destruktor nicht dafür zuständig, Code auszuführen, entsteht das Problem nicht, ebenso wie wenn es keine Ausnahmen geben würde. Wenn somit die Paradigmen 1 und 2 einander widersprechen, widersprechen sich die Paradigmen von C++ und somit in gewissem Masse auch C++ selbst.

Die Argumentation lässt sich leicht auch virtuelle Funktionen und RAII übertragen; wenn der Konstruktor uneingeschränkt Initialisierungen vornehmen soll und gleichzeitig eingeschränkt ist (er kann keine abgeleiteten Funktionen aufrufen), dann ist etwas faul.

Die versprochene Kritik an der Standardbibliothek:

std::string s; // RAII: s ist fertig initialisiert und kann verwendet werden
std::cin >> s; // stdc++: s wird gleich nochmal initialisiert, hä???

RAII wäre folgendes:

std::string s(std::cin.read<std::string>()); // Kopierkonstruktor

Wie das Paradigma heisst, welches hier angewendet wird, weiss ich nicht, vielleicht "Operatorenüberladung um jeden Preis". Jedenfalls kommt es nicht mit "ein Objekt wird nur einmal initialisiert" zurecht.

...sondern betrachte als Beispiel eine file -Klasse in modernem C++.

Was für eine file Klasse? Verstehe gerade nicht ganz wovon du redest. FILE ist nicht C++.

sprachbarriere schrieb:

Aus 1. folgt: Konstruktor öffnet die Datei, Destruktor schliesst die Datei.

Nicht wirklich. Kleines Beispiel:

std::auto_ptr<int> pi(new int(4));

Da wird im Konstruktor von auto_ptr nirgends irgend eine Ressource (in dem Fall also Speicher) alloziert. Das geschieht durch den Aufruf des new-operators. Allerdings initialisiere ich den auto_ptr mit dem zurückgegebenen pointer.

sprachbarriere schrieb:

Aus 2. folgt: Bei irgend einem Fehler beim Öffnen/Schliessen der Datei wird eine exception geworfen.
Schlussfolgerung: Der Destruktor muss manchmal eine Ausnahme werfen.

Nicht der Destruktor wirft die Exception, sondern ggf. der code der hier ausgeführt wird. Das ist aber ja auch kein Problem, mann muss entsprechend nur dafür sorgen, dass der Destruktor die exception nicht propagiert.
Möglichkeiten hat man ja genug (anderen exception handler setzen, Exception einfach schlucken, abort aufrufen etc.). Muss im Destruktor code ausgeführt werden, der möglicherweise eine exception wirft, dann bietet man i.d.R. ein öffentlich Methode an die diesen code ebenfalls ausführt um dem Benutzer die Möglichkeit zu geben, nach eigenem Gutdünken auf diese exception zu reagieren.

sprachbarriere schrieb:

Die Argumentation lässt sich leicht auch virtuelle Funktionen und RAII übertragen; wenn der Konstruktor uneingeschränkt Initialisierungen vornehmen soll und gleichzeitig eingeschränkt ist (er kann keine abgeleiteten Funktionen aufrufen), dann ist etwas faul.

Erstmal: was hat das jetzt mit RAII zu tun? Seh ich keinen Zusammenhang.
Wie soll denn während der Konstruktion eines Objektes auf noch nicht konstruirte member zugegriffen werden? Die Reihenfolge der Konstruktoren-Aufrufe ist dir hoffentlich klar. Dann dürfte auch klar sein, warum zum Zeitpunkt der Konstruktion des Basisklassenteils eines Objekts das Objekt auch nur als Typ dieser Basisklasse behandelt werden kann (und tatsächlich zu dem Zeitpunkt auch eins ist - alles andere wurde ja noch nicht konstruiert).

sprachbarriere schrieb:

Die versprochene Kritik an der Standardbibliothek:

std::string s; // RAII: s ist fertig initialisiert und kann verwendet werden
std::cin >> s; // stdc++: s wird gleich nochmal initialisiert, hä???

Wieso wird bei std::cin>>s der string nochmal initialisiert. Wird er nicht.

Grüsse

Ich danke euch.
Greetz C0de4Fun

Was für eine file Klasse? Verstehe gerade nicht ganz wovon du redest. FILE ist nicht C++.

Mein Fehler, gemeint war std::fstream . Aber das hindert uns nicht daran, das Gleiche als file zu implementieren.

inter2k3 schrieb:

Kleines Beispiel:

std::auto_ptr<int> pi(new int(4));

Da wird im Konstruktor von auto_ptr nirgends irgend eine Ressource (in dem Fall also Speicher) alloziert.

Gegenbeispiel:

std::vector<int>(4);

Tenor: Kommt auf den Kontext drauf an.
Mein Beispiel ist nicht aus der Luft gegriffen, genau die Klasse file wird auch in der englischen (und deutschen) Wikipedia unter RAII angeführt.

inter2k3 schrieb:

Das ist aber ja auch kein Problem, mann muss entsprechend nur dafür sorgen, dass der Destruktor die exception nicht propagiert.
Möglichkeiten hat man ja genug (anderen exception handler setzen, Exception einfach schlucken, abort aufrufen etc.).

Das sind die von mir im ersten Post als "unpassende und hässliche[n] Verrenkungen" bezeichnete Gegenmassnahmen. Nicht, dass es nicht möglich wäre, einen Workaround auszuwählen, aber keiner kann von sich behaupten, rein auf Exception-Denken begründet zu sein.

inter2k3 schrieb:

sprachbarriere schrieb:

Die Argumentation lässt sich leicht auch virtuelle Funktionen und RAII übertragen [...]

Erstmal: was hat das jetzt mit RAII zu tun?

Du siehst meinen Punkt nicht. Die Initialisierungsreihenfolge kommt aus technischen Überlegungen zustande. Was soll zuerst erledigt werden. C++ hat sich für den ganzen Konstruktor entschieden (m.E. ist das auch richtig so). Nun muss der Konstruktor nicht nur Standardwerte setzen, sondern manchmal hochkomplexe Ressourcen anfordern. Dass genau dieser wichtige Teil Einschränkungen unterlegen ist, was alle möglichen Spezialisierungen betrifft, gefällt mir überhaupt nicht. Weil das in der Praxis zutage tritt, gibt es selbstverständlich wieder unzählige Workarounds, händisch übergebene Funktionspointer, Mehrfachvererbung um einen Member zu übergeben, aber wieder kann nichts davon behaupten, intuitiv und mit dem Konzept der virtuellen Funktionen übereinstimmendend zu sein.

inter2k3 schrieb:

Kleines Beispiel:

std::auto_ptr<int> pi(new int(4));

Da wird im Konstruktor von auto_ptr nirgends irgend eine Ressource (in dem Fall also Speicher) alloziert.

Gegenbeispiel:

std::vector<int>(4);

Findest du auch ein Beispiel, bei dem man nicht direkt "selbst Schuld" schreien will?

Dass genau dieser wichtige Teil Einschränkungen unterlegen ist, was alle möglichen Spezialisierungen betrifft, gefällt mir überhaupt nicht. Weil das in der Praxis zutage tritt, gibt es selbstverständlich wieder unzählige Workarounds, händisch übergebene Funktionspointer, Mehrfachvererbung um einen Member zu übergeben, aber wieder kann nichts davon behaupten, intuitiv und mit dem Konzept der virtuellen Funktionen übereinstimmendend zu sein.

Hast du ein Beispiel?