ich bastele gerade ein eigenes getline, das auch schon bei '\r' ohne '\n' stoppt, weil ich eine komische Datei habe.

Das funktioniert auch ganz gut, nur dass er die letzte Zeile nicht liest, weil das !myGetline gilt und die Schleife daher abbricht. Beispiel:

istream& getlineUntilLinebreakOrCarriage(istream & in, string& out)
{
	out.clear();
	char c;
	while(!in.eof() && in.get(c).good())
	{
		if(c == '\r')
		{
			c = in.peek();
			if(in.good() && c == '\n')
				in.ignore();
			break;
		}
		else if(c == '\n')
			break;

		out.append(1, c);
	}

	return in;
}

int main()
{
	ifstream ifs("C:/test/easyTest.txt");

	string str;
	int n = 0;
	while(getlineUntilLinebreakOrCarriage(ifs, str))
	{
		cout << n++ << ": " << str << '\n' << flush;
	}

	cout << "Read all: " << n << " lines.\n";

	int x;
        cin >> x;
        return 0;
}

Ausgabe:

0: Hallo
Read all: 1 lines.

easyTest.txt:

Hallo
Du!

Wahrscheinlich wieder so ein richtig dummer Fehler. Danke!

Grüssli

istream& getlineUntilLinebreakOrCarriage(istream & in, string& out)
{
	out.clear();
	char c;
	while(!in.eof() && in.get(c).good())
	{
		if(c == '\r')
		{
			c = in.peek();
			if(in.good() && c == '\n')
				in.ignore();
			in.clear(); // Löscht das failbit
			break;
		}
		else if(c == '\n')
			break;

		out.append(1, c);
	}

	return in;
}

Oder ist das aus irgendwelchen Gründen unsauber?

Leider beseitigt das mein Problem noch nicht. In meinem einfachen Beispiel endet die Datei auch mit \r\n, daher setzt peek kein failbit.

Vorteile: IO geht so wie gewohnt, keine Notwendigkeit spezielle Funktionen zu benutzen oder irgendetwas umzuschreiben:

#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/categories.hpp> 
#include <boost/iostreams/operations.hpp> 

#include <iostream>
#include <string>

namespace io = boost::iostreams;

struct line_feed_to_new_line
{
  typedef char              char_type;
  typedef io::input_filter_tag  category;

  template<typename Source>
  int get(Source& src)
        {
          int c = io::get(src);
          return c == '\r' ? '\n': c;
        }
};

int main()
{  
    io::filtering_istream in;
    in.push(line_feed_to_new_line());
    in.push(io::file_source("test.dat"));  // Eine Datei, die gemischte Zeilenumbrüche enthält

    int i=0;
    std::string out;
    while(getline(in,out)) std::cout << "Zeile " << i++ << ": " << out <<'\n';
}

Ist jetzt mit einem Einzelzeichenfilter nur als Demo gedacht, vielleicht reicht dir das schon. Falls Performance wichtig ist, programmier lieber einen Filter, der mehrere Zeichen auf einmal verarbeitet, z.B. einen multi_character_input_filter oder (falls es kein Problem ist, die ganze Datei im Speicher zu halten) einen aggregate_filter.

Oder guck mal den Quellcode des Boost newline-Filters an. Der sollte das nämlich eigentlich schon machen. Aber funktionierte bei mir nicht .

Und was soll dieses c == 11 ? '\n': c; ? Ein Vergleich auf 11? Also bitte

Ich würde allerdings auch überlegen, einen anderen Lösungsweg zu wählen. Habe mir auch überlegt, ob man da nicht was über streambuf machen könnte. Der Stream soll ja nur ungültig werden, wenn es einen fatalen Fehler gibt ( badbit ) oder er bereits am Anfang am Ende steht. Wenn während dem Lesen das Ende erreicht wird, soll er noch nicht auf einen ungültigen Zustand gesetzt werden. failbit dürfte eigentlich nie auftauchen.

Wenn die Testdatei von Eisflamme nun aus genau 2 Zeilen besteht und am Ende keine leere Zeile zu finden ist, wird die Funktion von Eisflamme nicht funktionieren. Seine Lösung ignoriert immer die letzte Zeile, weil dann das eofbit gesetzt ist.

Aber habe gerade zu wenig Zeit, mich da reinzuwühlen ...

Grüssli

Und was soll dieses c == 11 ? '\n': c; ? Ein Vergleich auf 11? Also bitte

Ach, da habe ich mich selbst verarscht. Ich habe erst eine Textdatei getippt und dann im Hexeditor die 10en (\n) durch 11en ersetzt. Und mich dann gewundert, warum ein Vergleich mit '\r' nicht klappt. Dabei ist '\r' eine 13!

Ich hab's oben editiert, damit eventuelle Leser das nicht falsch übernehmen.

Hmm, \r\n, gar nicht an die Windows-Konvention gedacht. Sollte nicht so schwer sein, dies auch noch abzufangen. Entweder über eine statische Helfervariable oder wenn man, wie ohnehin schon vorgeschlagen, einen der Filter implementiert, der gleich die ganze Sequenz vorliegen hat.

Ich habe Mal in der MSVC-Implementierung nachgeschaut, aber die scheint leider nicht so simpel gestrickt zu sein wie das, was ich mache. Achso und vielen Dank für die boost-Lösung, aber ich denke, das hier sollte sich auch mit Standardmitteln gut machen lassen (hoffe ich).

Ich will ja nur getline nachbauen mit einem kleinen Unterschied... eigentlich kann das doch nicht so schwierig sein, oder? Weeerner ^^

Im Prinzip ist das was Werner immer mit seinen Wunder-Streambufs macht, genau das was Boost::iostreams abstrahiert hat. Die haben eben einmal so einen Standard-Streambuffer geschrieben, den man beliebig mit eigenen Filterobjekten füttern kann.

Hoffe, meine Motive schockieren oder beleidigen niemanden.

template <char C>
std::istream& Char(std::istream& in)
{
    char c;
    if (in >> c && c != C)
        in.setstate(std::ios_base::failbit);
    return in;
}

template <char C, typename T>
std::istream& read_until(std::istream& in, T& v)
{
    return in >> v >> Char<C>;
}

template <char C>
std::istream& read_until(std::istream& in, std::string& s)
{
    return std::getline(in, s, C);
}

Mein erster Versuch ist:

istream& Breaker(istream& in)
{
	char c;
	if(in >> c && c != '\r' && c != '\n')
		in.setstate(ios_base::failbit);
	return in;
}

istream& customGetline(istream& in, string& str)
{
	return in >> str >> Breaker;
}

int main()
{
	ifstream ifs("C:/test/easyTest.txt");

	string str;
	int n = 0;
	//while(getlineUntilLinebreakOrCarriage(ifs, str))
	while(customGetline(ifs, str))
	{
		cout << n++ << ": " << str << '\n' << flush;
	}

	cout << "Read all: " << n << " lines.\n";

	int x;

	cin >> x;
}

Dieser führt leider zu nichts, keine einzige Zeile wird gelesen. Auch wenn ich statt != das intuitivere == benutze (im Breaker) erhalte ich nur eine Zeile. (Natürlich würde der Code mein Problem auch nicht lösen, ich will damit nur sagen, dass ich nicht Mal ansatzweise dahinkomme, wo ich hinwill ^^)

Returns true if either one of the error flags (failbit or badbit) is set on the stream. Otherwise it returns false.

operator! stört sich nicht an eof, das darauffolgende get erzeugt aber ein fail. Damit sollte sich das Problem lösen lassen.

istream& getlineUntilLinebreakOrCarriage(istream & in, string& out)
{
	out.clear();
	char c;

	if(in.eof())
	{
		in.setstate(ios_base::eofbit | ios_base::failbit);
		return in;
	}

	while(!in.eof() && in.get(c).good())
	{
		if(c == '\r')
		{
			c = in.peek();
			if(in.good() && c == '\n')
				in.ignore();
			in.clear();
			break;
		}
		else if(c == '\n')
			break;

		out.append(1, c);
	}

	if(in.eof())
	{
		in.clear();
		in.setstate(ios_base::eofbit);
	}

	return in;
}

in hat erst nen good-State, dann nutzt man get und er setzt gleichzeitig das failbit und das eofbit... um das zu erreichen, was ich möchte, lösche ich also das failbit einmal raus und überprüfe am Anfang auf das eof-Bit...

Aber das ist auch hässlich. Weiß hier niemand, wie man das "richtig" macht?

#include <streambuf> // Die beiden brauchen wir, hoffentlich habe ich nichts vergessen
#include <istream>     
#include <fstream>   // Die anderen drei sind nur für das Beispiel
#include <string>
#include <iostream>

class char_filter : public std::streambuf
{
public:
  char_filter(std::istream& in, char from, char to )
    : in(in) // Stream merken, um später den Streambuf wiederherstellen zu können
    , buf (in.rdbuf())   // Der Original-Streambuf. Daher kommen unsere Daten
    , from(traits_type::to_int_type(from)), to(traits_type::to_int_type(to)) // Für die Filterfunktion, immer schön abstrakt bleiben
  {
    in.rdbuf(this);  // Unseren Streambuf installieren
  }
  ~char_filter()
  {
    in.rdbuf(buf); // alten Streambuf wieder herstellen
  }

protected:
  virtual int_type underflow()  // Eine der Funktionen die ein istream benutzen könnte (und die tatsächlich etwas lesen) und die wir darum überschreiben möchten
  {
    int_type c = buf->sgetc();
    return (traits_type::eq_int_type( c, from )) ? to : c;  // Immer schön abstrakt bleiben bei den Typen und Abfragen
  }
  virtual int_type uflow()      // Die andere Funktion die drankommen könnte
  {
    int_type c = buf->sbumpc();
    return (traits_type::eq_int_type( c, from )) ? to : c;
  }
private:
  char_filter( const char_filter& );            // Macht den Streambuffer unkopierbar
  char_filter& operator=( const char_filter& ); // Sonst geht das mit dem Merken des unterliegenden Streams schief

  std::istream& in;
  std::streambuf* buf;
  int_type from, to;
};

int main()
{
  std::ifstream ifs("test.dat");
  char_filter foo(ifs, '\r', '\n'); // So lange foo lebt, wird ifs gefiltert
  // Das kann man natürlich auch anders handhaben, wie der Filter genau installiert wird, aber so ist ganz praktisch.

  int i=0;
  std::string out;
  while(getline(ifs,out)) std::cout << "Zeile " << i++ << ": " << out <<'\n'; 
}

Wie schon zuvor, überlasse ich die Sonderbehandlung von \r\n dem geneigten Leser. Mit dieser Vorgabe sollte es trivial zu erweitern sein.

P.S.: Und ich könnte viel schneller mit so etwas sein, wenn ich den Hex-Editor richtig bedienen könnte, um mir passende Beispiele zu erstellen .

edit: Sehr viele Edits: Die Kommentare verbessert

@SeppJ: beeindruckend!

Alles bei Werner Salomon gelernt .

Ich verstehe alles außer underflow und uflow. (die wohl overflow heißen sollte?)
Kann mir das jemand erklären?

Nein, overflow() ist etwas anderes (das spielt bei den Ausgaben vor). Beide Funktionen werden verwendet, wenn der interne Zwischenspeicher zu Ende ist, wobei sich ein paar Randbedingungen unterscheiden, wann welche benötigt wird.

Ich verstehe alles außer underflow und uflow. (die wohl overflow heißen sollte?)
Kann mir das jemand erklären?

Das wie und warum dazu findest du wiederum hier:
http://www.cplusplus.com/reference/iostream/streambuf/
Da sehen wir erst einmal oben die public-Member. Diese haben wir geerbt. Die verwalten irgendwie intern einen Puffer (ist ja ein Streambuf ) und stellen dem Stream ein Interface zur Verfügung. Der Stream wird nun diese Funktionen benutzen, um aus dem Puffer zu lesen. Und jetzt sieht du vielleicht schon, warum das Underflow heißt: Wenn der interne Puffer (unser Puffer!) leer gelesen ist, dann müssen neue Zeichen rein. Die Standardimplementierung dieser Funktionen (die wir tunlichst nicht überschreiben sollten!) ruft dann die passenden virtual-Memberfunktionen auf. underflow, wenn der Puffer neue Zeichen braucht und overflow wenn der Puffer voll ist (im Falle eines ostreams).
Es gibt auch eine Reihe weiterer virtueller Funktionen, aber wenn du die Beschreibungen liest, wirst du sehen, dass diese eine brauchbare Defaultimplementierung haben und einfach wieder die anderen Memberfunktionen aufrufen. Die wichtigen Funktionen sind die, die ich überschrieben habe (und overflow für Ausgabestreambufs), die per Default überhaupt nichts tun, außer Fehlerwerte zurück zu geben. Für so einen einfachen Filterstream wie diesen reicht das völlig aus. Wenn's etwas anspruchsvoller sein soll, kann man sich die anderen Funktionen auch mal näher ansehen.

So, nun wissen wir aber gar nicht, woher wir unsere Zeichen bekommen sollen. Und selbst wenn wir es wüssten, dann würde ich ungern die Funktionen zum Lesen aus Dateien nachbauen. Daher habe ich mir den alten Streambuf gemerkt. Da braucht man gar nicht wissen, was da genau dahinter steht. Dessen public-Memberfunktionen funktionieren für uns genau so gut wie für den ursprünglichen fstream. Wenn also jemand unseren Streambuf nach Zeichen fragt und unser interner Puffer leer ist, dann fragen wir einfach den alten Strambuf nach Zeichen und filtern diese. Was danach damit passiert oder wie das intern gehandhabt wird kann uns egal sein. Wir sitzen mit unseren virtuellen Funktionen an der Schlüsselstelle, wo jeder vorbei muss.

P.S.: Möglich, dass der Default-Streambuf gar keinen internen Puffer hat. Die Beschreibung von setbuf klingt irgendwie danach. Ich bin nicht so der Experte auf dem Gebiet. Egal, der Filebuf den wir intern benutzen wird sicherlich richtig gepuffert sein.

P.P.S.: Danke für die Frage, ich glaube ich habe das Gesamtkonzept gerade selber das erste Mal richtig verstanden. Ursprünglich stand hier eine ganz andere Erklärung wie ich es mir vorher vorgestellt habe, bis ich bei genauerem Nachdenken gemerkt habe, dass das gar nicht stimmen konnte.

sauber SeppJ, vielen Dank, das hat mir schon enorm weitergeholfen.

Ich habe jetzt folgenden Fall: Es kann sein, dass '\r' alleine vorkommt, '\n' alleine vorkommt oder '\r' nebst '\n' vorkommt. Ich muss also weg von der Einzeichen-Basis.

So wie ich das sehe, lässt sich das folgendermaßen umsetzen:
- '\r' nebst '\n' löse ich, indem ich nach Lesen von '\r' schaue, ob das nächste Zeichen '\n' ist und, falls ja, den get-Zeiger einfach weiterschiebe und '\n' zurückgebe
- '\r' ohne '\n' wird gelöst, indem ich beim Lesen von '\r' einfach '\n' zurückgebe und den get-Zeiger normal lasse (einfache Konvertierung)
- '\n' wird als normales Zeichen zurückgegeben

Dann lässt sich das normale getline wieder anwenden. Ist folgender Code wohl in Ordnung?

custom_streambuf::int_type custom_streambuf::underflow()
{
	int_type c = oldBuf.sgetc();

	if(traits_type::eq_int_type(c, 13)) // c == '\r'
	{
		// Are characters to read and is next one '\n'?
		if(in_avail() == 0)
			return traits_type::int_type(10); // '\n';
		int_type c2 = oldBuf.snextc(); // move pointer to next element

		if(traits_type::eq_int_type(c2, 10))
			return c2;

		// here: c2 != '\n', so we should move back
		oldBuf.sungetc();
	}

	// In case of '\n' or other digits, we can return just them
	return c;
}

custom_streambuf::int_type custom_streambuf::uflow()
{
	int_type c = oldBuf.sbumpc();

	if(traits_type::eq_int_type(c, 13)) // c == '\r'
	{
		// We are at the next character; is it '\n'?
		int_type c2 = oldBuf.sgetc();

		if(traits_type::eq_int_type(c2, 10)) // it is '\n', so we should move to next token but return '\n'
		{
			snextc();
			return c2;
		}

		// here: c2 != '\n', so this get-pointer place is just right
	}

	// In case of '\n' or other digits, we can return just them
	return c;
}

Ich bin nicht ganz sicher, ob dieses in_avail genau macht, was ich möchte, laut Doku liest es ja die Anzahl der noch zu lesenden Zeichen, auch falls der interne Puffer gerade leer ist, aus. Wenn das also >0 ist, kommt noch was, ansonsten ist wohl eof | fail der Fall.

Mein initiales Beispiel "Hallo Du!" funktioniert damit übrigens. Seht ihr irgendwelche Fehler?

Ungetestet:

class CRLF_filter : public std::streambuf
{
public:
  CRLF_filter(std::istream& in)
    : in(in) 
    , buf (in.rdbuf())  
  {
    in.rdbuf(this);
  }
  ~CRLF_filter()
  {
    in.rdbuf(buf); 
  }

protected:
  virtual int_type underflow() 
  {
    int_type c = buf->sgetc();
    if (traits_type::eq_int_type( c, LF ) && last_was_CR)
     {
      int_type c = buf->snextc();  // Nächstes Zeichen nehmen
      last_was_CR = false;      
     }
    if (traits_type::eq_int_type( c, CR ))
     {
       c = LF;
       last_was_CR = true;
     }
    return c; 
  }
  virtual int_type uflow()    
  {
    int_type c = buf->sbumpc();
    if (traits_type::eq_int_type( c, LF ) && last_was_CR)
     {
      int_type c = buf->sbumpc();  // Man beachte den Unterschied zu oben
      last_was_CR = false;      
     }
    if (traits_type::eq_int_type( c, CR ))
     {
       c = LF;
       last_was_CR = true;
     }
    return c; 
  }
private:
  char_filter( const char_filter& ); 
  char_filter& operator=( const char_filter& ); 

  std::istream& in;
  std::streambuf* buf;
  static const int_type CR, LF;
  bool last_was_CR;
}; 

CRLF_filter::int_type CRLF_filter::LF  = CRLF_filter::traits_type::to_int_type('\n');
CRLF_filter::int_type CRLF_filter::CR = CRLF_filter::traits_type::to_int_type('\r');

So, ich hoffe, ich habe da keine Dummheiten gemacht, die man erst bei Sonderfällen wie \r\EOF oder ähnlichem bemerkt.

Aber wenn \r\EOF endet, gilt last_was_CR; wenn ich die nächste Datei lese und die mit \n anfängt, wird das \n ignoriert. Können wir das noch irgendwie lösen?

Hm... wobei ich gerade überlege, ob dieser Fall überhaupt eintritt, ohne dass wir ein neues istream-Objekt haben..

Hm... wobei ich gerade überlege, ob dieser Fall überhaupt eintritt, ohne dass wir ein neues istream-Objekt haben..

Theoretisch könnte der Nutzer das Filterobjekt auch an einen anderen Stream binden, aber da wir keine Schnittstelle zur Verfügung stellen, kann er den Streambuf der unter unserem Stream liegt nicht ändern. Theoretisch könnte er diesen manipulieren, aber wer so etwas tut, soll auch mit den Konsequenzen leben. Das ist schließlich ein absichtlicher Hack. Und es wäre selbst dann auch konsistent: Der Streambuf filtert \r zu \n und \r\n zu \n. Woher die Zeichen kommen, sollte unserem Filter egal sein.

Jedenfalls brauchst du keine Angst zu haben, dass dir das bei normaler Benutzung passiert.

Ich habe jetzt ein paar Tests gemacht. Hier 5 Dateien:

48 61 6C 6C 6F 0A 44 75 21
48 61 6C 6C 6F 0D 44 75 21
48 61 6C 6C 6F 0D 44 75 0D 0A
48 61 6C 6C 6F 0D 44 75 0A
48 61 6C 6C 6F 0D 44 75 0D

(\r \n in der Mitte hatte ich vorher schon Mal getestet, das geht auch)

Ich erzeuge jeweils einen neuen istream und auch Buffer. Für diese fünf Dateien funktioniert alles.

Ein paar Kleinigkeiten habe ich im Code noch geändert, weil z.B. das lastCR-Flag bei normalen Zeichen nach \r nicht geändert wurde und so. Zur Vollständigkeit nochmal der Code:

custom_streambuf::int_type custom_streambuf::underflow()
{
	int_type c = oldBuf.sgetc();

	if(traits_type::eq_int_type(c, LF) && lastWasCR) // \r\n -> we are at \n
	{
		lastWasCR = false;
		// Ignore this
		return oldBuf.snextc();
	}
	if(traits_type::eq_int_type(c, CR)) // \r -> we memorize this but return \n
	{
		lastWasCR = true;
		return LF;
	}
	lastWasCR = false;

	return c;
}

custom_streambuf::int_type custom_streambuf::uflow()
{
	int_type c = oldBuf.sbumpc();

	if(traits_type::eq_int_type(c, LF) && lastWasCR) // \r\n -> we are at \n
	{
		lastWasCR = false;
		// Ignore this
		return oldBuf.sbumpc();
	}
	if(traits_type::eq_int_type(c, CR)) // \r -> we memorize this but return \n
	{
		lastWasCR = true;
		return LF;
	}
	lastWasCR = false;

	return c;
}

wenn man eine (Text-)Datei im sogenannten DOS-Format vorliegen hat - also mit dem "\r\n" als Zeilenende, dann ist für die Auflösung dieses Zeichenpaars IMHO die std::codecvt-Facette zuständig.

Das geht im Prinzip so:

#include <fstream>
#include <iostream>
#include <locale>
#include <string>

class ConvertCrLf2Lf : public std::codecvt< char, char, int >
{
protected:
    virtual bool do_always_noconv() const
    {
        return false;
    }
    // -- Einlesen
    virtual result do_in( state_type& state,
        const extern_type* from, const extern_type* from_end, const extern_type*& from_next,
        intern_type* to, intern_type* to_limit, intern_type*& to_next ) const
    {
        const char CR('\r');
        const char LF('\n');
        to_next = to;
        for( from_next = from; from_next != from_end && to_next != to_limit; ++from_next )
        {
            switch( state )
            {
            case 0: // normal
                if( *from_next == CR )
                    state = 1; // wir merken uns nur, dass CR da war
                else
                    *to_next++ = *from_next;
                break;

            case 1: // das vorherige Zeichen war CR
                if( *from_next != LF )
                {
                    *to_next++ = CR; // allein stehendes CR nachliefern
                    if( to_next == to_limit )
                        return std::codecvt_base::partial;
                }
                if( *from_next != CR )
                {
                    *to_next++ = *from_next;
                    state = 0;
                }
            }
        }
        return from_next == from_end? std::codecvt_base::ok: std::codecvt_base::partial;
    }
    // -- Ausgeben
    // virtual result do_out(stateT& state,
    //   const intern_type* from, const intern_type* from_end, const intern_type*& from_next,
    //   extern_type* to, extern_type* to_limit, extern_type*& to_next) const { ...
};

int main()
{
    using namespace std;
    ifstream in("input.txt"/*, ios_base::binary*/ );  // s.u. bei Windows
    in.imbue( locale( in.getloc(), new ConvertCrLf2Lf ) );
    for( string line; getline( in, line ); )
        cout << "> " << line << endl;
    return 0;
}

Die Facette kann mit imbue an den Stream und damit an den Streambuf übergeben werden. Jeder basic_filebuf sollte auch was damit anfangen können. Bei Windows-Systemen ist das aber nie notwendig; dort reicht es die Datei im Textmode zu öffnen - d.h. ohne das binary (s.o.). Wenn man es unter Windows ausprobieren will, so muss die Datei binär geöffnet werden und - ganz wichtig - VC10 benutzen, da die älterne Versionen einen Fehler haben - siehe codecvt<char,char>-Problem.

Habe i.A. nicht so viel Zeit, noch mehr in die Tiefe zu gehen; mehr zum Thema hatten wir im Forum schon mal hier.

Gruß
Werner