fstream sofort nutzen

[Xin]

Ich habe heute auch mal eine Frage....

Folgendes Programm:

Code: Alles auswählen

#include <iostream>
#include <fstream>

using namespace std;

void writeLog(string logInfo)
{
  fstream f("autoviertel.log", fstream::app | fstream::out);
  f<< logInfo;
}

int main()
{
  writeLog( std::string( "bla" ));
}

Das funktioniert.

Nun ist die Variable f eigentlich vollkommen überflüssig.

Code: Alles auswählen

void writeLog(string logInfo)
{
  fstream("autoviertel.log", fstream::app | fstream::out) << logInfo;
}

Das hier lässt sich nicht kompilieren?!

Er findet keinen passenden operator <<.
Warum nicht?

[Xin]

... und schon habe ich eine Vermutung...

Qnf grzcbeäer Bowrxg vfg pbafg.

[nufan]

Qnf grzcbeäer Bowrxg vfg pbafg.

Richtig, ostream hat keinen operator<< für std::string ^^ Folgendes:

Code: Alles auswählen

fstream("autoviertel.log", fstream::app | fstream::out) << logInfo.c_str();

funktioniert ohne Probleme.
Siehe: http://www.cplusplus.com/reference/iost ... tor%3C%3C/

[Xin]

Qnf grzcbeäer Bowrxg vfg pbafg.

Richtig, ostream hat keinen operator<< für std::string ^^ Folgendes:

Code: Alles auswählen

fstream("autoviertel.log", fstream::app | fstream::out) << logInfo.c_str();

funktioniert ohne Probleme.
Siehe: http://www.cplusplus.com/reference/iost ... tor%3C%3C/

"Qnf grzcbeäer Bowrxg vfg pbafg." heißt "Das temporäre Objekt ist const."

Wieso funktioniert dann:

Code: Alles auswählen

void writeLog(string logInfo)
{
  fstream f("autoviertel.log", fstream::app | fstream::out);
  f<< logInfo;
}

[nufan]

Hm... ok, war doch ne blöde Idee. Ich schätze mal der Compiler findet einfach die globalen Operatoren nicht, weil diese eine Referenz auf den Stream benötigen, was mit dem konstanten Objekt nicht möglich ist. Mit this scheint das zu gehen, deswegen funktionieren einige Operatoren die direkt in der Klasse implementiert sind trotzdem.

[fat-lobyte]

Dani hats rausgefunden!

Der operator << erwartet eine nicht-const Referenz. Temporäre Objekte sind aber stets nur const ref, und eine nicht-const-ref kann nicht an eine const-ref binden: http://stackoverflow.com/questions/1565 ... ary-object

Das macht insofern Sinn, dass es nichts bringt temporäre Objekte zu verändern, weil sie ja sowieso gleich wieder verschwinden, zumindest war das eine der Argumentationen die ich irgendwo gesehen habe. Auf jeden Fall gibts nen guten Grund dazu.

Probier das mal auf Visual Studio aus, die haben ziemliche Bugs was das Binden an Referenzen betrifft. Vielleicht funktioniert das dort!

Außerdem: versuch einfach mal das Temporäre Objekt in std::move() zu packen. Ich glaube das sollte gehn.

[fat-lobyte]

Aha! Man muss das gar nicht in std::move packen, man muss nur C++11 einschalten damit genau das funktioniert was du willst.

Was dann passiert: Das temporäre Objekt ist dann keine const-lvalue-ref (const &) mehr, sondern eine rvalue-ref (&&). Diese bindet nach den Faltungsregeln[1] als lvalue ref als parameter des Operators.

Ein weiterer Fall, wie C++11 die Sprache "gratis" verbessert hat

[1] http://thbecker.net/articles/rvalue_ref ... on_08.html

[Xin]

Hm... ok, war doch ne blöde Idee. Ich schätze mal der Compiler findet einfach die globalen Operatoren nicht, weil diese eine Referenz auf den Stream benötigen, was mit dem konstanten Objekt nicht möglich ist. Mit this scheint das zu gehen, deswegen funktionieren einige Operatoren die direkt in der Klasse implementiert sind trotzdem.

this ist hier nicht mehr const, da das Objekt lokal ist und damit nicht ganz so temporär, wie das temporäre Objekt.

Dani hats rausgefunden!

Hmm? Ich dachte, ich hätte es rausgefunden!?

Der operator << erwartet eine nicht-const Referenz.

linksseitig... was ja auch halbwegs logisch ist, schließlich wird das linksseitige Objekt verändert - auch wenn es nicht darum geht, das Objekt zu verändern, sondern das Objekt die Datei verändern zu lassen: Qnf grzcbeäer Bowrxg vfg pbafg.

Außerdem: versuch einfach mal das Temporäre Objekt in std::move() zu packen. Ich glaube das sollte gehn.

Ich soll fstream in std::move packen!? Weshalb!?

Was dann passiert: Das temporäre Objekt ist dann keine const-lvalue-ref (const &) mehr, sondern eine rvalue-ref (&&). Diese bindet nach den Faltungsregeln[1] als lvalue ref als parameter des Operators.

Die muss ich mir auch endlich mal anständig zu Gemüte führen, ich hasse es, wenn Du damit als Biochemiker(?) oder was Du studierst rumwedelst und ich als Informatiker das Gefühl habe, auf Glatteis zu stehen... das bin ich so nicht gewohnt.

[fat-lobyte]

Hmm? Ich dachte, ich hätte es rausgefunden!?

Richtig, so genau hab ich jetzt auch nicht nachgelesen.

auch wenn es nicht darum geht, das Objekt zu verändern, sondern das Objekt die Datei verändern zu lassen: Qnf grzcbeäer Bowrxg vfg pbafg.

Die verschlüsselung hab ich immer noch nicht gecheckt, aber es macht schon Sinn: das Objekt verändert nicht nur die Datei, sondern hat auch einen internen Zustand (z.B. File pointer, ...) der beim Schreiben zwangsläufig verändert wird. Das objekt kann und soll nicht const-beschreibbar sein, das würde sonst die const-correctness untergraben.

Ich soll fstream in std::move packen!? Weshalb!?

Die Grundidee war, dass du aus einem temporären Objekt statt einem lvalue-const-ref ein rvalue-ref machst. Das geschieht in C++11 anscheinend sowieso, also ist std::move unnötig, siehe zweites posting.

Die muss ich mir auch endlich mal anständig zu Gemüte führen, ich hasse es, wenn Du damit als Biochemiker(?) oder was Du studierst rumwedelst und ich als Informatiker das Gefühl habe, auf Glatteis zu stehen... das bin ich so nicht gewohnt.

Molekuarbioge (Bach.)/Biotechnologie (Mast.), wenn du's genau wissen willst
Dadurch, dass ich etwas komplett anderes Studiere, betrachte ich Programmieren als Hobby, als Entspannung. Mir solche Dinge zu gemüte zu führen ist für mich das Äquivalent eines Kreuzworträtsels. Das Kreuzworträtsel war 2009 schon ziemlich spannend, und seit dem Beschäftige ich mich mit C+11. Wenn ich mich recht entsinne war deine einstellung damals dazu "es gibt noch keine Compiler, es ist noch nichtmal fixiert und ich beschäftige mich später damit". Ich habe damals schon angefangen und seitdem ein Bisschen was gelernt. Ist es da verwunderlich, dass ich ausnahmsweise einen kleinen Vorsprung habe?

[Xin]

auch wenn es nicht darum geht, das Objekt zu verändern, sondern das Objekt die Datei verändern zu lassen: Qnf grzcbeäer Bowrxg vfg pbafg.

Die verschlüsselung hab ich immer noch nicht gecheckt, aber es macht schon Sinn: das Objekt verändert nicht nur die Datei, sondern hat auch einen internen Zustand (z.B. File pointer, ...) der beim Schreiben zwangsläufig verändert wird. Das objekt kann und soll nicht const-beschreibbar sein, das würde sonst die const-correctness untergraben.

Schon klar... also ab meinem zweiten Posting...

Die Verschlüsslung ist die übliche Verschlüssung, wenn es eigentlich keine Verschlüsslung ist, sondern eher ein "Spoileralarm": rot13. Früher zu Mailboxzeiten, gab's Leute, die rot13 ohne Decoder gelesen haben, irgendwann hatte man es einfach im Blick.

Die muss ich mir auch endlich mal anständig zu Gemüte führen, ich hasse es, wenn Du damit als Biochemiker(?) oder was Du studierst rumwedelst und ich als Informatiker das Gefühl habe, auf Glatteis zu stehen... das bin ich so nicht gewohnt.

Molekuarbioge (Bach.)/Biotechnologie (Mast.), wenn du's genau wissen willst

Molekuarbiogie wäre nix für mich. Zuviele komplizierte Fremdworte, ich könnte nichtmals meine Berufsbezeichnung richtig schreiben.

Dadurch, dass ich etwas komplett anderes Studiere, betrachte ich Programmieren als Hobby, als Entspannung. Mir solche Dinge zu gemüte zu führen ist für mich das Äquivalent eines Kreuzworträtsels. Das Kreuzworträtsel war 2009 schon ziemlich spannend, und seit dem Beschäftige ich mich mit C+11. Wenn ich mich recht entsinne war deine einstellung damals dazu "es gibt noch keine Compiler, es ist noch nichtmal fixiert und ich beschäftige mich später damit". Ich habe damals schon angefangen und seitdem ein Bisschen was gelernt. Ist es da verwunderlich, dass ich ausnahmsweise einen kleinen Vorsprung habe?

Nicht verwunderlich - aber bedauerlich ;-D

Du darfst als Student mit all den schönen Spielzeugen spielen, während ich irgendwo zwischen Fortran -> C -> C++ hänge und bis vor kurzem noch Visual Studio 6 kompatibel programmieren durfte...
Und bei privaten Projekten scheitere ich schon an "nullptr", weil Visual C++ "nullptr" nunmal nicht mag. Dafür mag Visual C++ override, aber GCC nicht.