Getline wird nicht beachtet

patrick246

Weil es unnötig ist. encode wird automatisch mit verlassen des Scopes geschlossen.

JBHillmann

ohh ok also schlicht unnötig

JBHillmann

ofstream encode;//konstuktor
encode.open("encode.txt");//konstruktor!

und hier ist was falsch? Ohne eins von beidem funktionierts nicht?

~(Edit v. Arcoth, Code-Tags)~

volkard

JBHillmann schrieb:

ofstream encode;//konstuktor
encode.open("encode.txt");//konstruktor!

und hier ist was falsch? Ohne eins von beidem funktionierts nicht?

ofstream encode("encode.txt");//Diesen Konstruktor benutzen statt Defaultkonstruktor und open.

Nexus

JBHillmann schrieb:

und warum regt man sich hier über encode.close(); auf?

Unnötiges Ressourcenschliessen ist ein typisches Anzeichen dafür, dass Leute RAII -- und damit eines der wichtigsten Konzepte in C++ überhaupt -- nicht verstanden haben.

Nexus schrieb:

JBHillmann schrieb:

und warum regt man sich hier über encode.close(); auf?

Unnötiges Ressourcenschliessen ist ein typisches Anzeichen dafür, dass Leute RAII -- und damit eines der wichtigsten Konzepte in C++ überhaupt -- nicht verstanden haben.

Ein close() hinauszuzögern nur weil der Code dadurch kompakter wird ist ein typisches Anzeichen dafür, dass Leute die Nachteile von RAII bewusst ignorieren.

Hier kommt es vielleicht auf das gleiche drauf raus, aber wenn schon mit Exceptions argumentiert wird darf ich auch den allgemeinen Fall betrachten:

ofstream encode("encode.txt");
encode << "test";

<berechnung>
return <something>

Die Datei wird hier erst am Ende des Scopes geschlossen. Die maximale Anzahl offener Dateien ist sehr beschrängt, wenn bei <berechnung> nochmal eine Datei geöffnet wird, hat man u.U. Probleme. Besser:

ofstream encode("encode.txt");
encode << "test";
auto position = encode.tellg(); // einfach damit man encode nicht so einfach in einen Block stecken kann
endode.close(); // nicht mehr benötigt => sofort zumachen

<berechnung>
return <something>

SeppJ

releaseearlyandoften schrieb:

Die maximale Anzahl offener Dateien ist sehr beschrängt

lol. 16k oder mehr.

ofstream encode("encode.txt");
encode << "test";
 
<berechnung>
return <something>

Dein Fehler: Variablen nicht lokal gehalten und der Funktion keine klare Aufgabe gegeben.

SeppJ schrieb:

releaseearlyandoften schrieb:

Die maximale Anzahl offener Dateien ist sehr beschrängt

lol. 16k oder mehr.

16k sind nicht viel. Bei mir sind im Normalbetrieb 6k-7k offen (/proc/sys/fs/file-nr). Viele dateifressende Prozesse sind nicht so einfach zu verkraften.

ofstream encode("encode.txt");
encode << "test";
 
<berechnung>
return <something>
Dein Fehler: Variablen nicht lokal gehalten und der Funktion keine klare Aufgabe gegeben.

(Du hast wohl absichtlich die Zeile auto position = encode.tellg(); // einfach damit man encode nicht so einfach in einen Block stecken kann ignoriert. War schon klar, dass da jemand mit der Bemerkung kommt.)

Sehr idealistische Sichtweise. Wenn du es schon genau nimmst:

string f() {
  ifstream input("input.txt");
  string s;
  input >> s;
  return s; // s wird in Rückgaberegister kopiert: Kann u.U. lange dauern und ist sehr speicherintensiv
            // (C++11 mit Move-Semantik behebt dieses Beispiel aber lange nicht alle Probleme)
  // input wird geclosed und viel Speicher wird freigegeben.
}

Oder auch dieser typische Codeausschnitt:

vector<int> v = f();
int x = accumulate(v.begin(), v.end(), 0);
v.clear(); // v wird nicht mehr benötigt, aber x schon

Schreibst du da wirklich jedesmal eine eigene Funktion?

SeppJ

releaseearlyandoften schrieb:

SeppJ schrieb:

releaseearlyandoften schrieb:

Die maximale Anzahl offener Dateien ist sehr beschrängt

lol. 16k oder mehr.

16k sind nicht viel. Bei mir sind im Normalbetrieb 6k-7k offen (/proc/sys/fs/file-nr). Viele dateifressende Prozesse sind nicht so einfach zu verkraften.

Pro Prozess, du Experte! Aber da du dich ja offensichtlich viel besser auskennst, als jeder andere Mensch auf der Erde, brauche ich dir ja wohl mehr nicht zu erklären.

Nexus

releaseearlyandoften schrieb:

Nexus schrieb:

Unnötiges Ressourcenschliessen ist ein typisches Anzeichen dafür, dass Leute RAII -- und damit eines der wichtigsten Konzepte in C++ überhaupt -- nicht verstanden haben.

Ein close() hinauszuzögern nur weil der Code dadurch kompakter wird ist ein typisches Anzeichen dafür, dass Leute die Nachteile von RAII bewusst ignorieren.

Bitte genau lesen, das "unnötig" steht nicht ohne Grund da. Wenn es semantisch Sinn macht, kann man Ressourcen natürlich vorher schliessen. Aber so oft, wie du das gerade darzustellen versuchst, kommt das nicht vor, wenn man Scopes vernünftig wählt.

releaseearlyandoften schrieb:

Oder auch dieser typische Codeausschnitt:

vector<int> v = f();
int x = accumulate(v.begin(), v.end(), 0);
v.clear(); // v wird nicht mehr benötigt, aber x schon

Lustig ist ja, dass clear() gar nichts freigibt. Scheint, als müsstest du all diese "typischen" Codeausschnitte umschreiben

Nathan

releaseearlyandoften schrieb:

[[/cpp]Oder auch dieser typische Codeausschnitt:
vector<int> v = f();
int x = accumulate(v.begin(), v.end(), 0);
v.clear(); // v wird nicht mehr benötigt, aber x schon
Schreibst du da wirklich jedesmal eine eigene Funktion?

Ich versteh nicht wo das Problem ist?
Wenn die Funktion danach wirklich noch lang ist (was sie nicht sein sollte, 15 Zeilen max), macht man halt so:

int x;
{
  vector<int> v = f();
  x = accumulate(v.begin(), v.end(), 0);
}

volkard

Nexus schrieb:

releaseearlyandoften schrieb:
Oder auch dieser typische Codeausschnitt:
vector<int> v = f();
int x = accumulate(v.begin(), v.end(), 0);
v.clear(); // v wird nicht mehr benötigt, aber x schon
Lustig ist ja, dass clear() gar nichts freigibt. Scheint, als müsstest du all diese "typischen" Codeausschnitte umschreiben

Keiner der Ausschnitte kam mir typisch vor.
Habs Gefühl, daß uns gerade der Meister persönlich besuchen gekommen ist.

volkard

Nathan schrieb:

Wenn die Funktion danach wirklich noch lang ist (was sie nicht sein sollte, 15 Zeilen max), macht man halt so:
int x;
{
  vector<int> v = f();
  x = accumulate(v.begin(), v.end(), 0);
}

Und dann kann man später auch nicht mehr aus Versehen auf v zugreifen. Sehr fein, wenn es mehr Compilerfehler gibt. Vor allem, wenn man da noch 15 Zeilen dranklatschen will.

Nathan

volkard schrieb:

Vor allem, wenn man da noch 15 Zeilen dranklatschen will.

Ich sagte 15 Zeilen max.

JBHillmann

Ok ich als Neuling würde jetzt nach dieser Diskussion gerne wissen ob man entweder mit close() schließen soll wenn es nicht mehr benötigt wird oder ob man es mit dem ende des scopes gut sein lässt oder ob man es extra umschreibt wie in folgendem Beispiel

Nathan schrieb:

int x;
{
  vector<int> v = f();
  x = accumulate(v.begin(), v.end(), 0);
}

Und muss mann das jetzt schließen um Ressourcen zu schonen oder ist das nicht notwendig?

volkard

JBHillmann schrieb:

Ok ich als Neuling würde jetzt nach dieser Diskussion gerne wissen ob man entweder mit close() schließen soll wenn es nicht mehr benötigt wird oder ob man es mit dem ende des scopes gut sein lässt oder ob man es extra umschreibt wie in folgendem Beispiel

Nathan schrieb:
int x;
{
  vector<int> v = f();
  x = accumulate(v.begin(), v.end(), 0);
}
Und muss mann das jetzt schließen um Ressourcen zu schonen oder ist das nicht notwendig?

Normalerweise kann man es gut sein lassen. Schlechtes Gefühl dabei behalten im Falle von Dateien, bei Dateien lieber ein Scope im die Datei. Sollte das auch nicht gehen, dann erstmal überlegen, ob da nicht was kleines eh in eine eigene Funktion gewollt hätte. Damit hab ich jahrelang Ruhe. So ein x (oder fileSize) aus dem Datei-Scope rauszumachen ist schon ungewöhnlich. Aber wenns sein muss, muss es eben sein. Und wo close() halt sein muss, macht man's (ist aber selten). Die Kenntnis über die fileSize brauche ich nicht länger als wie die Datei offen ist für den Fortschrittsbalken. Oder ich brauche nur die fileSize und nicht den Dateiinhalt, dann wird's eine Funktion getFileSize. Wo brauche ich eine fileSize, die länger lebt als die Datei offen ist und nicht schon innerhalb der Funktion auf den dicken Zähler aufaddiert werden könnte?
Also ich kann nur sagen, daß ich close() selten oder nie brauche.

JBHillmann

Vielen Dank an alle ihr habt mich echt weiter gebracht