RAII
-
Vollständig bedeutet, dass die File bereits benutzbar sein soll. (Oder allgemeiner, keine Initialisierung mehr vorgenommen werden muss)
-
Generell hat es 2 Gründe, statt open lieber den Konstruktor zu verwenden. Erstens spart man eine Zeile und Zweitens kommt man nicht in Gefahr, ein nicht vollständig initialisiertes Objekt zu verwenden. Erstens mag unwichtig sein, aber Zweitens tritt häufiger auf als man denkt.
Wenn du z.B. mal mit C# oder Java programmiert hast, wirst du auf einige Stellen stoßen, wo du Objekte auf null prüfen musst, weil sie möglicherweise noch nicht initialisiert sind. In C++ gibt es sowas nicht. Jedes Objekt wird garantiert im Konstruktor initialisiert.
RAII geht jetzt noch einen Schritt weiter. Im konkreten Fall ist garantiert, dass der Stream geöffnet ist. Entweder das, oder er wird gar nicht erstellt (Exception). Das Fehlerpotential wird also noch weiter verringert. Und warum sollte man das nicht nutzen?
Dass trotzdem open und close angeboten wird, ist zu Gunsten der Fexibilität. Es gibt schon Anwendungen, wo ein explizites Öffnen und Schließen des Streams gewünscht ist, man wollte den Programmierer also nicht einschränken, nur sind diese selten und sollten in jedem Fall überdacht werden (weil in solchen Situationen das erwähnte Fehlerpotential wieder entsteht).
-
ipsec schrieb:
Wenn du z.B. mal mit C# oder Java programmiert hast, wirst du auf einige Stellen stoßen, wo du Objekte auf null prüfen musst, weil sie möglicherweise noch nicht initialisiert sind. In C++ gibt es sowas nicht. Jedes Objekt wird garantiert im Konstruktor initialisiert.
Dass trotzdem open und close angeboten wird, ist zu Gunsten der Fexibilität. Es gibt schon Anwendungen, wo ein explizites Öffnen und Schließen des Streams gewünscht ist, man wollte den Programmierer also nicht einschränken, nur sind diese selten und sollten in jedem Fall überdacht werden (weil in solchen Situationen das erwähnte Fehlerpotential wieder entsteht).
zum ersten: ja im studium wird java gelehrt und danke. das ist mal einr ichtig gutes argument dem ich auch voll zustimmen würde...
zum zweiten: also kann ich in meinen eigenen klassen ruhig initialisierungs methoden anbieten, aber auch neben einem konstruktor der diese itnern aufruft und damit das objekt schon bereit zur arbeit macht?
(stimmt der technische aspekt denn, das open im konstruktor von fstream aufgerufen wird?)wie sieht das denn analog dazu mit deinitialierungs methoden aus z.b. exit oder fstream::close(); ?
-
ipsec schrieb:
RAII geht jetzt noch einen Schritt weiter. Im konkreten Fall ist garantiert, dass der Stream geöffnet ist. Entweder das, oder er wird gar nicht erstellt (Exception).
http://cplusplus.com/reference/iostream/fstream/fstream/
sagt dazu:
If the constructor is not successful in opening the file, the object is still created although no file is associated to the stream buffer and the stream's failbit is set (which can be checked with inherited member fail).Außerdem:
Constructs an object of the fstream class. This implies the initialization of the associated filebuf object and the call to the constructor of its base class with the filebuf object as parameter.und:
Additionally, when the second constructor version is used, the stream is associated with a physical file as if a call to the member function open with the same parameters was made.Die Frage ist einfach, ist das Objekt nicht auch initialisiert, wenn ich einfach nur den Standardkonstruktor benutze.
Es ist schließlich nutzbar. Und an der Ressourcenfreigabe bei Verlassen des Scopes ändert sich nichts.
-
Skym0sh0 schrieb:
(stimmt der technische aspekt denn, das open im konstruktor von fstream aufgerufen wird?)
Vermutlich ja (zumindest würde ich es so implementieren).
Belli schrieb:
ipsec schrieb:
RAII geht jetzt noch einen Schritt weiter. Im konkreten Fall ist garantiert, dass der Stream geöffnet ist. Entweder das, oder er wird gar nicht erstellt (Exception).
http://cplusplus.com/reference/iostream/fstream/fstream/
sagt dazu:
If the constructor is not successful in opening the file, the object is still created although no file is associated to the stream buffer and the stream's failbit is set (which can be checked with inherited member fail).Ups. Ich habe ganz vergessen, dass Exceptions bei Streams standardmäßig nicht verwendet werden. In diesem Fall ist das aber ein Schwäche von den Streams, welche RAII nicht 100%-ig sauber umsetzen.
Skym0sh0 schrieb:
wie sieht das denn analog dazu mit deinitialierungs methoden aus z.b. exit oder fstream::close(); ?
Ähnlich. Wenn du das Objekt explizit schließt, könnte es passieren, dass du danach noch darauf zugreifst. Das wird verhindert, wenn das Schließen erst dann erfolgt, wenn das Objekt selbst zerstört wird.
-
Skym0sh0 schrieb:
zum zweiten: also kann ich in meinen eigenen klassen ruhig initialisierungs methoden anbieten, aber auch neben einem konstruktor der diese itnern aufruft und damit das objekt schon bereit zur arbeit macht?
(stimmt der technische aspekt denn, das open im konstruktor von fstream aufgerufen wird?)Grundsätzlich ist es sinnvoll Schnittstellen so anzulegen, das man sie möglichst nicht falsch benutzen kann. Ich bin z.B. kein Fan von separaten Initialisierungsroutinen (Zumal der Begriff eine Initialisierung andeutet, es kann aber nach dem Konstruktor nur noch ein Zuweisen/Überschreiben sein), falls solche wirklich nötig sind, greife ich zu Fabrikmethoden oder ähnlichen (Wo der Aufruf die Erzeugung beinhaltet, und ein gültiges Objekt (Meist über einen Smartpointer) zurück gibt.
-
ipsec schrieb:
Ups. Ich habe ganz vergessen, dass Exceptions bei Streams standardmäßig nicht verwendet werden. In diesem Fall ist das aber ein Schwäche von den Streams, welche RAII nicht 100%-ig sauber umsetzen.
kurz mal offtopic: ich hab mal irgendwo gelesen, dass exceptions bööse sind und von schlechtem design zeugen. stimmt das?
oder ist es ok diese zu verwenden?
-
Skym0sh0 schrieb:
ipsec schrieb:
Ups. Ich habe ganz vergessen, dass Exceptions bei Streams standardmäßig nicht verwendet werden. In diesem Fall ist das aber ein Schwäche von den Streams, welche RAII nicht 100%-ig sauber umsetzen.
kurz mal offtopic: ich hab mal irgendwo gelesen, dass exceptions bööse sind und von schlechtem design zeugen. stimmt das?
oder ist es ok diese zu verwenden?Es ist absolut ok! Im Gegenteil, die Alternativen sind oft schlechtes Design. Die Quelle, wo du solche Aussagen gelesen hast, würde ich mit Vorsicht betrachten. RAII und Exceptions passen auch gut zusammen, zum einen bekommt man mit RAII Exceptionsicherheit fast geschenkt, zum anderen sind Exceptions die Lösung, um Fehler bei der Objektinitialisierung im Konstruktor anzuzeigen. Lediglich im Destruktor sollte man keine Exceptions werfen (übrigens noch ein Grund für close - in dem seltenen Fall, dass der Erfolg des Schließens wirklich von Belang ist, kann man es damit prüfen).
-
Ich denke "RAII" versteht jeder ein bisschen anders. Für mich ist es das Stichwort, womit ich folgendes in Verbindung bringe:
Es ist oft extrem praktisch, die Verwaltung von Resourcen an Objekte und deren Lebenszeit zu knüpfen. Seien es Dinge wie Dateien oder auch dynamisch allozierte, andere Objekte bzw Speicherbereiche. Ich stelle mir diese Objekt/Besitz/Resourcen-Beziehungen gerne als Wald aus lauter Bäumen (bzw manchmal auch nur azyklische Graphen) vor, bei dem eine gerichtete Kante von x nach y bedeutet "x besitzt/verwaltet y". Den automatischen Speicher und den statischen Speicher zähle ich zu der Knotenmenge und sind bei mir immer die einzigen Wurzeln, da eine neue Resource entweder direkt in diesem Speicher lebt oder sofort mintestens einem anderen Besitzer zugeordnet wird. Hält man sich daran, wird sich das Thema "resource leaks" auch in Hinblick auf fliegende Ausnahmen erledigt haben. Das einzige, was da noch schief gehen kann, sind Dinge wie baumelnde Zeiger bzw Referenzen. Das kommt dann nur vor, wenn man Design-technisch Besitzverhältnisse falsch gewählt hat.
Die Kurzfassung: RAII macht das Leben leichter, da die Verantwortung bzgl der Verwaltung von Resourcen an Objekte deligiert wird und man sich selbst nicht mehr darüber den Kopf so dolle zerbrechen muss, wann man wo etwas freigeben muss.
Ob nun "Zwei-Phasen-Initialisierung" oder nicht, ist eine andere Geschichte. Ich würde hier immer noch von RAII sprechen. Ob eine Klasse noch einen "Nullzustand" bekommen soll oder nicht, muss man für sich im konkreten Fall entscheiden.
Da ich Ausnahmebehandlung lieber mag als "if()goto", habe ich mir folgendes bei Funktionen angewöhnt, die von sich aus keine Ausnahme im Fehlerfall schmeissen:
#if __cplusplus > 199800L #include <utility> #define MOVE(x) ::std::move(x) #else #define MOVE(x) (x) #endif namespace { void enforce(bool what, const char errmsg[]) { if (!what) { string em = "Fehler in Modul XY: "; em += errmsg; throw my_module_specific_error(MOVE(em)); } } } [....] /// @throws my_module_specific_error void dings::bums() { [....] ifstream ifs (dateiname); enforce(ifs,"konnte dies und das nicht oeffnen"); [....] }
-
krümelkacker schrieb:
Ob nunr "Zwei-Phasen-Initialisierung" oder nicht, ist eine andere Geschichte. Ich würde hier immer noch von RAII sprechen.
Das ist auch meine Meinung - schön auf den Punkt gebracht.
-
krümelkacker schrieb:
Ob nunr "Zwei-Phasen-Initialisierung" oder nicht, ist eine andere Geschichte. Ich würde hier immer noch von RAII sprechen. Ob eine Klasse noch einen "Nullzustand" bekommen soll oder nicht, muss man für sich im konkreten Fall entscheiden.
"Zwei-Phasen-Initialisierung" ist eigentlich schon ein Widerspruch in sich. Mit einer Init Methode ist die Verwaltung der Ressource von der Lebensdauer des Objektes zumindest halb entkoppelt. Im Falle von fstream ist durch open() und close() praktisch alles von der Lebensdauer entkoppelt, das Objekt stellt nur noch die Freigabe der Ressource in jedem Fall sicher. Streng genommen entspricht das also nichtmehr der Bezeichnung RAII. Aber ja, es entspricht imo wohl noch dem wesentlichen Teil des Idioms. Vielleicht sollte man zwischen strong oder weak RAII unterscheiden oder so :p
-
Stroustrup sieht das ähnlich - bei RAII geht es um das Aufräumen angeforderter Ressourcen. Allerdings ist Stroustrup auch der Meinung, dass Objekte in der Regel gleich bei der Konstruktion initialisiert werden sollten (TC++PL E.3.5.3).
Was Exceptions angeht, so ist RAII unverzichtbar für Exceptionsicherheit, aber RAII kann problemlos auch ohne Exceptions betrieben werden. Wann Exceptions zur Fehlerbehandlung Sinn machen, ist heftig umstritten und ein Stück weit Ansichtssache. Grob über den Daumen sehe ich es so, dass das Werfen von Exceptions dann Sinn macht, wenn ich in einer Situation bin, in der ich davon ausgehen kann, dass bei seinem Auftreten der umgebende Code nicht mehr vernünftig weiter machen kann. Etwa, wenn ich eine Datumsklasse schreibe und der umgebende Code versucht, den 53. Juni zusammenzustellen.
-
Nachtrag: Ich wollte hier krümelkacker zustimmen, aber da hat sich dot wohl dazwischengedrängt.
-
seldon schrieb:
Etwa, wenn ich eine Datumsklasse schreibe und der umgebende Code versucht, den 53. Juni zusammenzustellen.
Ist hierfür ein assert() nicht besser geeignet?
Meiner Meinung nach sollten Exceptions nur dort verwendet werden, wo die Zuständigkeit des Programmierers endet. Zum Beispiel bei IO.
-
Der 53. Juni kann ja nicht nur durch einen klasseninternen Fehler zustandekommen, sondern auch durch den Benutzer, z.B. wenn dieser versucht, die Instanz mit dem 53. Juni 2011 zu initialisieren. Eine Exception ist demnach angebracht.
Edit: wobei man natürlich als Klassendesigner kein korrektes Verhalten garantieren muss, wenn man sie mit ungültigen Werten füttert. Damit wird die Eingabevalidation dem Nutzer der Klasse überlassen.
-
dot schrieb:
krümelkacker schrieb:
Ob nunr "Zwei-Phasen-Initialisierung" oder nicht, ist eine andere Geschichte. Ich würde hier immer noch von RAII sprechen. Ob eine Klasse noch einen "Nullzustand" bekommen soll oder nicht, muss man für sich im konkreten Fall entscheiden.
"Zwei-Phasen-Initialisierung" ist eigentlich schon ein Widerspruch in sich. Mit einer Init Methode ist die Verwaltung der Ressource von der Lebensdauer des Objektes zumindest halb entkoppelt.
Strenggenommen bräuchte man dann überhaupt keine Set-Methoden mehr?!
-
Warum das denn?
Set-Funktionen ändern doch auch Werte, insb. auch solche Werte, die nur einen Default-Wert bekommen haben.
-
Belli schrieb:
Strenggenommen bräuchte man dann überhaupt keine Set-Methoden mehr?!
Wie kommst du den da drauf? Es soll durchaus möglich sein, den Objektzustand später noch zu verändern.
(Wobei natürlich trotzdem viele Setter, besonders in Anfängerprogrammen, total unnötig sind. Aber das hat nicht direkt mit dem Thema zu tun)
edit: Zu langsam.
-
314159265358979 schrieb:
seldon schrieb:
Etwa, wenn ich eine Datumsklasse schreibe und der umgebende Code versucht, den 53. Juni zusammenzustellen.
Ist hierfür ein assert() nicht besser geeignet?
Meiner Meinung nach sollten Exceptions nur dort verwendet werden, wo die Zuständigkeit des Programmierers endet. Zum Beispiel bei IO.Äh...assert ist eigentlich als Debugging-Tool gedacht. Es ist die Aussage "hier muss dies oder das der Fall sein, sonst ist irgendwo ein Programmierfehler gemacht worden". Üblicherweise wird das aus Releaseversionen ja auch einfach rauskompiliert.
Jedenfalls ist der Gedanke genau falsch herum - einfach abzustürzen ist in Ordnung, wenn dir Hardware abraucht oder sonstige Dinge passieren, für die du nun wirklich überhaupt nicht planen kannst, aber kein Benutzer dankt es dir, wenn dein Programm abstürzt, bloß weil er sich in einem Eingabefeld vertippt. Und die Prüfung, ob es sich um ein gültiges Datum handelt, aus der Datumsklasse herauszunehmen, wäre für mein Verständnis ziemlich geisteskrankes Design.
Was die "Zwei-Phasen-Initialisierung" angeht: Diese Problematik ist von RAII völlig abgekoppelt. Ob ein Objekt initialisiert ist, ist eher eine programmlogische Frage - ein std::vector ist initialisiert und einsatzbereit, bevor er das erste mal Speicher anfordert, und den Speicher, den er anfordert, kann er auch während seiner Lebensdauer wieder freigeben (wenn er beispielsweise vergrößert wird).
Worum es bei RAII geht, ist, dass Ressourcen, sobald sie angefordert wurden, sofort einem Eigentümer unterstellt werden, der sich um ihre spätere Freigabe kümmert. Wie und wann der das macht, ist eine andere Frage; wichtig ist allein, dass nichts verloren geht (Destruktoren spielen hier natürlich eine große Rolle, aber nicht alle Ressourcen werden erst im Destruktor freigegeben, und nicht alle Destruktoren geben verwaltete Ressourcen wieder frei - shared_ptr lässt grüßen). Ob die Eigentümerschaft über Ressourcen bereits im Konstruktor oder später übernommen wurde, ist dafür gleichgültig.
-
SeppJ schrieb:
Wie kommst du den da drauf? Es soll durchaus möglich sein, den Objektzustand später noch zu verändern.
Wobei durchaus die Meinung existiert zumindest Value Objects, also Objekte deren Identität durch ihren Zustand bestimmt ist immutable zu machen, also keine Setter anzubieten und stattdessen immer neue Objekte zu verwenden.
Wobei das denke ich in C++ weniger bedeutsam ist als in C# oder Java. Ich habe die Bedeutung zumindest aus C++ Sicht nie wirklich verstanden, wenn ich davon las.
