string in klasse

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.

Gucky

macht sinn, aber wenn man die klasse nicht als referenz übergibt macht das nichts, oder?

Gucky schrieb:

macht sinn, aber wenn man die klasse nicht als referenz übergibt macht das nichts, oder?

Wenn man sie als Kopie ohne const übergibt, ist das egal, da es ja dann wie gesagt eine Kopie ist. const erlaubt hier halt zu steuern ob eine Funktion den Inhalt eines Objekts ändern darf oder nur die getter verwenden soll. Achja, innerhalb einer Funktion die hintendran const hat, darf auch der Inhalt von Membervariablen nicht geändert werden. Es hat also eine doppelte Schutzfunktion.
Generell sollte man const durchaus einsetzen bei Gettern oder Methoden die nichts am Zustand der Klasse ändern.
rya.

Gucky

kann man statt dem ofstream eigentlich auch fstream benutzten??

theta

Gucky schrieb:

kann man statt dem ofstream eigentlich auch fstream benutzten??

ja.