string in klasse

Braunstein

Scorcher24 schrieb:

Leider ist das im Standard scheinbar nicht definiert wie der Constructor von exception auszusehen hat -.-.
rya.

Doch, das ist definiert. Siehe Standard 18.6.1 1-3
Für std::exception selber gibt es keinen Konstruktor der etwas übernimmt (CopyCtor ausgenommen).
Da muss man sich was draus ableiten, oder die vordefinierten Typen von stdexcept nutzen.

SeppJ

@Scorcher24: Warum schließt du die Datei im Destruktor?

Gucky

ok, danke für die vielen antworten, werde sie alle mal in ruhe durchlesen

Braunstein schrieb:

Scorcher24 schrieb:

Leider ist das im Standard scheinbar nicht definiert wie der Constructor von exception auszusehen hat -.-.
rya.

Doch, das ist definiert. Siehe Standard 18.6.1 1-3
Für std::exception selber gibt es keinen Konstruktor der etwas übernimmt (CopyCtor ausgenommen).
Da muss man sich was draus ableiten, oder die vordefinierten Typen von stdexcept nutzen.

Hmm, danke aber da finde ich die M$-Implementation echt besser...

@SeppJ
Warum nicht? Kommt immer drauf an, was man möchte. Es ist zumindest nichts falsches dabei... zumal die Klasse nen reiner Wrapper für ofstream darstellt und eigentlich relativ sinnlos wäre in einem ernsthaften Programm, ausser man implementiert ein gewisses Verhalten beim Lesen&Schreiben.
rya.

Shade Of Mine

Scorcher24 schrieb:

Hmm, danke aber da finde ich die M$-Implementation echt besser...

hat alles vor und nachteile.
string in der exception klasse fuehlt sich aber falsch an, da bad_alloc fliegen koennte...

Warum nicht?

weils unnoetig ist. der dtor von fstream raeumt selber auf.

Shade Of Mine schrieb:

Scorcher24 schrieb:

Hmm, danke aber da finde ich die M$-Implementation echt besser...

hat alles vor und nachteile.
string in der exception klasse fuehlt sich aber falsch an, da bad_alloc fliegen koennte...

Hmm, mag sein. Hab das nicht studiert :p. Aber nichts empfinde ich als schlimmer als ständige Exceptions ohne zu wissen wo der Fehler liegt. Gutes Beispiel hierfür wäre CEGUI. Viel zu viel Exceptions ohne gescheite Beschreibung des Fehlers.

Shade Of Mine schrieb:

Scorcher24 schrieb:

Warum nicht?

weils unnoetig ist. der dtor von fstream raeumt selber auf.

Okay, aber schaden tuts auch nicht .
rya.

Shade Of Mine

Scorcher24 schrieb:

Hmm, mag sein. Hab das nicht studiert :p. Aber nichts empfinde ich als schlimmer als ständige Exceptions ohne zu wissen wo der Fehler liegt. Gutes Beispiel hierfür wäre CEGUI. Viel zu viel Exceptions ohne gescheite Beschreibung des Fehlers.

Deshalb ist es wichtig tiefe Exception Hierachien zu haben.
Weil eine Fehlerbeschreibung in der Exception ist OK. Aber viel besser ist eine eigene Exception Klasse fuer einen Fehlertyp. Denn dann kann man im Code darauf reagieren. zB die Aktion wiederholen, oder alternativen versuchen.

Wenn nur eine std::exception fliegt, dann kann das alles bedeuten...

Okay, aber schaden tuts auch nicht

es schadet der coolness

Shade Of Mine schrieb:

Wenn nur eine std::exception fliegt, dann kann das alles bedeuten...

Okay, aber schaden tuts auch nicht

es schadet der coolness

man weiß nicht obs funktionierte und excpetions im detor sind böse

Shade Of Mine

p;sep;se schrieb:

es schadet der coolness

man weiß nicht obs funktionierte und excpetions im detor sind böse

Keine Ahnung was du meinst. Das close im DTor ist unnoetig. Es gibt keine Situation wo es etwas anderes macht als der dtor vom fstream objekt nicht sowieso machen wuerde. exceptions fliegen hier in keinem fall.

Files im detor schließen ist eigentlich garkeine gute idee

Shade Of Mine

p;sep;se schrieb:

Files im detor schließen ist eigentlich garkeine gute idee

Besser als eine close Funktion zu erfinden.

PS: wenn du etwas sagen willst, dann formuliere das bitte aus und poste nicht jeden satz einzeln.

Der std::stream der im Detor aufräumt, ist keine gute Idee.
Wenn close noch etwas ins File schreiben muss, weil noch kein flush kam, weißt du nicht obs funktionierte, weil das objekt dann weg ist. Und Exception werfen: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9

l'abra d'or

p;sep;se schrieb:

man weiß nicht obs funktionierte und excpetions im detor sind böse

Es wird sicher funktionieren, sonst gäbe es keine Funktion close(). Der Destruktor wird intelligent genug sein, ein close bleiben zu lassen, wenn der fstream gerade nicht offen ist. Und close wirft nur eine exception, wenn exceptions für das Objekt aktiviert sind (laut Doku).
Und seit wann sind Exceptions im DTor böse? Ich behaupte das Gegenteil und sage Exceptions im DTor sind was wunderbares!
Das was böse endet ist, wenn eine Exception den DTor verlässt. Wenn wirklich im DTor was passieren kann, musst du das alles fangen.

Ich glaub aber deine Posts gehen stark in Richtung getrolle.

l'abra d'or schrieb:

Und close wirft nur eine exception, wenn exceptions für das Objekt aktiviert sind (laut Doku).
Und seit wann sind Exceptions im DTor böse? Ich behaupte das Gegenteil und sage Exceptions im DTor sind was wunderbares!
Das was böse endet ist, wenn eine Exception den DTor verlässt. Wenn wirklich im DTor was passieren kann, musst du das alles fangen.

Woher weißt du ob std::stream im Detor erfolgreich geschlossen wurde?

Shade Of Mine

p;sep;se schrieb:

Woher weißt du ob std::stream im Detor erfolgreich geschlossen wurde?

Irrelevant, du kannst auf destruktor fail nicht reagieren. und close() ist ein dtor fail.

aber diese diskussion habe ich schon 50mio mal gehabt, such im forum mal.

Shade Of Mine schrieb:

p;sep;se schrieb:

Woher weißt du ob std::stream im Detor erfolgreich geschlossen wurde?

Irrelevant

Wenn deine Daten nicht wichtig sind, ja.

Gucky

zu dem beispiel von scorcher24 und zwar würde ich gerne wissen:
1. wofür man sstream braucht
2. was die bitverknüpfung macht std::ofstream& operator<<(const std::string& t);
3. und bei den funkionen das : m_dateiname(dateiname) macht

gruß gucky

padreigh

1: google "c++ sstream API" lesen, Beispiele anschaun, nachdenken, bei Unverständnis gezielt nachfragen
2: nix Bitverknüpfung, übergabe des strings per const reference (spart kopieren), rückgabe des streams per referenz was Verkettungen ermöglicht:

std::cout                << " a "                                   << " b " ;
// stream               kriegt ein                            der zurückgelieferte stream 
//                const char[] und liefert                      kriegt einen const char[] 
//                  einen stream zurück                       und liefert wieder nen stream 
//                                                               zurück der ignoriert wird

3: Keine Funktionen sondern Konstruktoren: google "Initialisierungsliste c++"

Gucky

zwei fragen hab ich noch und zwar was macht das zweite const bei

const std::string& dateiname() const { return m_dateiname; }

und warum muss man ein sstream beim throw benutzten und diesen dann in einen c-string umwandeln?? oder sehe ich das falsch?

Gucky schrieb:

zwei fragen hab ich noch und zwar was macht das zweite const bei
const std::string& dateiname() const { return m_dateiname; }
und warum muss man ein sstream beim throw benutzten und diesen dann in einen c-string umwandeln?? oder sehe ich das falsch?

1.) Das const an vorderer Stell sorgt dafür, dass der Inhalt der Referenz nicht veränderbar ist, ausser durch schmutzige Dinge wie const_cast. Das zweite const sorgt dafür, dass die Funktion auch aufrufbar ist wenn die Klasse als const pointer oder referenz übergeben wird. Kleines Beispiel ausm Stehgreif:

#include <string>

class foo
{
public:
   const std::string& GetA1() const { return m_a; }
   const std::string& GetA2() { return m_a; }

private:
  std::string m_a;
};

void bar(const foo& a)
{
   a.GetA1(); // <- okay
   a.GetA2(); // <- fehler, siehe quote
}

int main()
{
   foo test;
   bar(test);
}

test2.cpp: In function 'void bar(const foo&)':
test2.cpp:16: error: passing 'const foo' as 'this' argument of 'const std::string& foo::GetA2()' discards qualifiers

2.) Muss man nicht, nur es geht schneller. Noch dazu ist ja wie angemerkt, nur die stdlib des msvc in der Lage eine Fehlermeldung im Constructor einer Exception anzunehmen.
rya.