ifstream objekt als rückgabewert?

hi,
ich habe gelesen, das ein streamobjekt nicht kopierbar ist.

ifstream open_file ( char* file )
{
	ifstream infile (file);
	return infile;
}

prinzipiell ist obiges also gar nicht möglich? oder doch irgendwie?

volkard

stream0r schrieb:

hi,
ich habe gelesen, das ein streamobjekt nicht kopierbar ist.
ifstream open_file ( char* file )
{
	ifstream infile (file);
	return infile;
}
prinzipiell ist obiges also gar nicht möglich? oder doch irgendwie?

Das ist nicht möglich.

Nexus

stream0r schrieb:

prinzipiell ist obiges also gar nicht möglich? oder doch irgendwie?

Nein, und das ist auch gut so.

Verwende stattdessen Referenzen oder Zeiger (evtl. sogar Smart Pointer). Stelle auf jeden Fall sicher, dass die Objekte nach der Rückgabe noch existieren. Oder konstruiere den Stream ausserhalb der Funktion und übergib eine Referenz darauf.

Badestrand

Müsste das nicht mit RValue-Referenzen gehen? Das Objekt würde dann ja verschoben und nicht kopiert werden, man kann dann* ja afaik auch 'ifstream's in einem vector halten

*dann = Wenn die Bibliotheken umgestellt sind.

Nexus

Badestrand schrieb:

Müsste das nicht mit RValue-Referenzen gehen?

RValue-Referenzen darf man doch nicht an LValues binden, oder? Sofern man den std::ifstream nicht temporär erstellt, könnte das ein Problem werden. Ich muss dazu allerdings sagen, dass ich mich mit den neuen Sprachmitteln nicht besonders gut auskenne, das wäre einfach meine Vermutung.

Move-Semantik kannst du aber auch mit std::auto_ptr erreichen (in letzter Zeit gefällt mir dieser Smart Pointer richtig :)).

Badestrand schrieb:

man kann dann* ja afaik auch 'ifstream's in einem vector halten

Kann man das? Referenzen in Containern speichern? Und falls ja, hätte man nicht das gleiche Problem wie mit std::auto_ptr in Containern?

Badestrand

Nexus schrieb:

RValue-Referenzen darf man doch nicht an LValues binden, oder?

Doch, man kann explizit angeben, wenn man sie nicht mehr braucht, müsste dann so aussehen:

ifstream open_file ( char* file )
{
    ifstream infile (file);
    return std::move(infile);
}

Obwohl ich mir gerade unsicher bin, ob das nicht schon automatisch passiert. Einfach weil das Objekt im Moment des Zurückgebens den LValue-Status verliert. Oder so.

Nexus schrieb:

Move-Semantik kannst du aber auch mit std::auto_ptr erreichen (in letzter Zeit gefällt mir dieser Smart Pointer richtig :)).

Hehe, schlechter Zeitpunkt. Irgendwer hatte hier vor ein paar Tagen diesen echt guten Artikel zu den RValue-Referenzen gepostet. Darin steht unter Anderem, dass auto_ptr in C++0x deprecrated wird, aber ersetzt wird durch unique_ptr (aber mit, soweit ich verstanden habe, selber Funktionalität).

Nexus schrieb:

Badestrand schrieb:

man kann dann* ja afaik auch 'ifstream's in einem vector halten

Kann man das? Referenzen in Containern speichern? Und falls ja, hätte man nicht das gleiche Problem wie mit std::auto_ptr in Containern?

Huch, gute Frage, ob man dann Referenzen in einen Container packen kann. Also ich meine jedenfalls, man kann nicht-kopierbare Objekte in den vector packen (nicht Referenzen auf diese, die Objekte selbst). Das klappt halt, weil ja immer nur eine Instanz existiert und die Algorithmen in der Implementierung nur verschieben und nie kopieren.

Nexus

Du scheinst ja recht fasziniert von den neuen Möglichkeiten zu sein...

Badestrand schrieb:

Hehe, schlechter Zeitpunkt. Irgendwer hatte hier vor ein paar Tagen diesen echt guten Artikel zu den RValue-Referenzen gepostet. Darin steht unter Anderem, dass auto_ptr in C++0x deprecrated wird, aber ersetzt wird durch unique_ptr (aber mit, soweit ich verstanden habe, selber Funktionalität).

Ja, davon hab ich auch schon gehört. Momentan finde std::auto_ptr aber noch praktisch. Danke übrigens für den Artikel, den werde ich bei Gelegenheit mal anschauen.

Badestrand schrieb:

Huch, gute Frage, ob man dann Referenzen in einen Container packen kann. Also ich meine jedenfalls, man kann nicht-kopierbare Objekte in den vector packen (nicht Referenzen auf diese, die Objekte selbst). Das klappt halt, weil ja immer nur eine Instanz existiert und die Algorithmen in der Implementierung nur verschieben und nie kopieren.

Hmm, ich weiss nur, dass std::auto_ptr diesbezüglich Schwierigkeiten macht. Keine Ahnung wies mit RValue-Referenzen aussieht, haben die überhaupt Objektstatus? Vielleicht werden aber wie du sagst auch Algorithmen sofern möglich kompatibel gemacht. Ich sollte mich mal auf jeden Fall einmal genauer über RValue-Referenzen informieren...

Aber ehrlich gesagt finde ich, braucht man dieses Feature (RValue-Referenzen in Containern) nicht unbedingt. Da kommt man mit momentanen Mitteln wie Boosts Pointer-Container schon sehr gut aus.

Dravere

Nexus schrieb:

Kann man das? Referenzen in Containern speichern? Und falls ja, hätte man nicht das gleiche Problem wie mit std::auto_ptr in Containern?

Ich habe mal gelesen, dass es möglich sein soll. Aber hilf mir mal schnell auf die Sprünge, was war schon wieder das Problem mit std::auto_ptr in einem Container? Es ist spät, ich weiss gerade nur noch, dass man es nicht machen kann, nur nicht mehr wieso

Badestrand schrieb:

Hehe, schlechter Zeitpunkt. Irgendwer hatte hier vor ein paar Tagen diesen echt guten Artikel zu den RValue-Referenzen gepostet. Darin steht unter Anderem, dass auto_ptr in C++0x deprecrated wird, aber ersetzt wird durch unique_ptr (aber mit, soweit ich verstanden habe, selber Funktionalität).

Die Funktionialität ist nur indirekt dieselbe. Ein std::unique_ptr ist eigentlich nichts anders als ein boost::scoped_ptr , welcher weder CopyConstructible noch CopyAssignable ist, was im Gegensatz dazu der std::auto_ptr allerdings ist. Der Unterschied ist, dass der std::unique_ptr MoveConstructible und MoveAssignable ist, wodurch er sich wie ein std::auto_ptr verhalten kann.

Grüssli

Nexus

Dravere schrieb:

Ich habe mal gelesen, dass es möglich sein soll. Aber hilf mir mal schnell auf die Sprünge, was war schon wieder das Problem mit std::auto_ptr in einem Container? Es ist spät, ich weiss gerade nur noch, dass man es nicht machen kann, nur nicht mehr wieso

Folgendes Axiom ist nicht erfüllt:

T a = b;
assert (a == b);

Hier können Probleme entstehen, zum Beispiel wenn innerhalb eines Algorithmus eine Kopie eines Elements angelegt wird, das Originalobjekt aber trotzdem nicht verändert werden soll.

Was std::unique_ptr betrifft: Genau, soviel ich verstanden habe, soll er einfach nicht mehr implizit seinen Besitz verschieben, weil das oft zu Problemen führt. Über std::move kann man diese Semantik explizit herbeiführen.

Badestrand

Nexus schrieb:

Du scheinst ja recht fasziniert von den neuen Möglichkeiten zu sein...

C++ wirkt manchmal leicht angestaubt, da tun die neuen Sprachmittel wirklich gut.

Nexus schrieb:

Aber ehrlich gesagt finde ich, braucht man dieses Feature (RValue-Referenzen in Containern) nicht unbedingt. Da kommt man mit momentanen Mitteln wie Boosts Pointer-Container schon sehr gut aus.

Och, mit "gut lösbar mit reiner std-lib" und "Performance noch und nöcher" gibt's immerhin schon zwei gute Argumente