RAII

asc

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.

Skym0sh0

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?

ipsec

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).

krümelkacker

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");
  [....]
}

Belli

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.

dot

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.

314159265358979

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.

Athar

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.

Belli

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?!

Jockelx

Warum das denn?
Set-Funktionen ändern doch auch Werte, insb. auch solche Werte, die nur einen Default-Wert bekommen haben.

SeppJ

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.

brotbernd

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.

SeppJ

brotbernd schrieb:

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.

Das klingt in C++ nach einem Fall für const. Wobei ich kein großer Fan von temporären const-Objekten bin, sofern das nicht der Compilezeitoptimierung dient. Ich sollte als Programmierer selber wissen, ob ich meine Objekte verändern will oder nicht. Wenn ich den Begriff Value Object richtig verstehe, macht das dort aber durchaus Sinn - das ist dann wohl auch wieder so etwas wie eine Compilezeitkonstante.

brotbernd

Hm ich weiß nicht.. Ich hab neulich Evans 'Domain Driven Design' gelesen, da hat er sich darüber ausgelassen. Ich habs nicht wirklich verstanden. Bei Fowler hab ich sowas auch mal gelesen. Die Sachen sind aber oft ziemlich von Java geprägt, darum hab ich vermutet dass das irgendwie in der Ecke seinen Ursprung hat.

SeppJ

Ich kenne mich mit fortschrittlichem Java-Design nicht so aus, aber ist nicht so etwas gemeint?

int zehn = 10;
date erster_januar = Date(1,1);
string hello_world = "Hello World!";

Das sind so typische Fälle (hier ein bisschen an den Haaren herbeigezogen, weil ich gerade faul bin), wo die Identität eines Objekts gleichbedeutend mit seinem Wert ist und wo es durchaus Sinn macht, diese deshalb vor Veränderung zu schützen. Was immer das jeweilige Mittel der Sprache zu diesem Zweck ist.

Aber wir entgleisen gerade den Thread...

krümelkacker

dot schrieb:

krümelkacker schrieb:

[...]

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.

"Zwei-Phasen-Initialisierung" ist eigentlich schon ein Widerspruch in sich.

Wie gesagt, das versteht wohl jeder etwas anders. Initialisierung gibt es in zweierlei Hinsicht: (1) Die Sprache C++ selbst verwendet das Wort "Initialisierung" in Kombination mit "direct initialization", "copy initialization" oder "list initialization", jeweils verschiedene Syntaxen für die Initialisierung. (2) "Logische" Initialisierung = Initialisierung im Sinne von Punkt 1 oder Veränderung eines existierenden Objekts in einen Zustand, den man bei der anwendungsspezifischen Modellierung als "initialisiert" betrachtet (was auch immer das sein wird). Wenn man bei RAII an den zweiten Punkt denkt, passt auch "two-phase-initialization" in das Konzept rein.

Ich ziehe es vor, die Dinge unabhängig voneinander zu betrachten. Bei der einen Sache geht es darum, Resourcen irgendwelchen Besitzer-Objekten zuzuordnen und damit Verwaltungsaufwand zu deligieren und für Ausnahmesicherheit zu sorgen. Bei der anderen Sache geht es darum, ob für die entsprechende Klasse ein "Nullzustand" eher nützt oder schadet. Bei Klassen wie std::string, std::vector und std::unique_ptr<> macht so ein Zustand, in dem keine zusätzlichen Resourcen benötigt werden, durchaus Sinn. Bei den stream-Klassen ist das eher eine Grauzone, würde ich sagen. Wenn diese Stream-Klassen einen solchen Zustand nicht anböten, man ihn aber für eine bestimmte Anwendung gut gebrauchen könnte, müsste man sich so etwas mit boost::optional oder std::unique_ptr nachbauen. Ob so ein Nullzustand für eine Klasse sinvoll ist, kann ich pauschal nicht beantworten. Das kommt auch darauf an, wieviel Aufwand es ist, so einen Nullzustand in die Invariante aufzunehmen und wie nervig es im Benutzercode sein wird, auf diesen Zustand prüfen zu müssen.

dot schrieb:

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.

Ein Objekt, kann die Verwaltung einer Resource nur übernehmen, sofern es existiert -- nicht vorher und nicht nachher. Was während der Existenz des Objekts passiert (swap, move semantics, open/close etc), ist mir egal. Hautsache Resourcen werden schnellstmöglich einem Besitzer-Objekt zugeordnet. Das und nur das verstehe ich unter RAII, wie schon erwähnt. Wenn Du einen anderen Begriff dafür hast, sag ihn mir. Klassen mit hohem Aufwand auf beiden Seiten der Schnittstelle einen künstlichen "Nullzustand" aufzuzwängen, halte ich aber auch für eine blöde Idee. Die Stream-Klassen fühlen sich IMHO wie unique_ptr für spezielle Stream-Buffer an. Da kann ich auch einen Nullzustand tolerieren.

dot schrieb:

Streng genommen entspricht das also nichtmehr der Bezeichnung RAII.

Mit der Bezeichnung ist sowieso keiner glücklich.

Gruß,
kk

krümelkacker

seldon schrieb:

...

Ah, Deinen Beitrag hatte ich übersehen. Da hätte ich mir die lange Antwort sparen können.