3. grosse Dateien lesen

grosse Dateien lesen

  • A

    also du meinst so:

    leser::liesdatei("foo.txt");//selbsterklärend
char buffer[1024];//erwarte das keine Zeile grösser als 1024
while(leser::nächstezeile(buffer)){//wenn keine Zeile überig return false
interpreter::interpretiere(buffer);}//selbsterklärend
leser::schliess
    0
  • K

    Du könntest Memmory Mapped Files benutzen.
    Die gibt es sowohl für UNIX/Posix basierte Betriebssysteme, als auch für Windows.

    http://msdn.microsoft.com/en-us/library/ms810613.aspx
    http://en.wikipedia.org/wiki/Memory-mapped_file
    http://en.wikipedia.org/wiki/Mmap

    Gruß,
    Klaus

    0
  • ?

    über 100 aufrufe und niemand meckert wegen fgets? 😕
    das ist doch c!
    wenn du also in c programmierst, und eine aus eventuell mehreren zeilen bestehende datei komplett in den ram laden möchtest, dann nimm fread.

    0
  • A

    okay, aber mein neues system wär auch ok?

    0
  • ?

    ohne zu wissen, in welchem zusammenhang dein "system" läuft, wird dir das niemand beantworten können.

    0
  • A

    Ich frage ob dieses system Nachteile hat:

    leser::liesdatei("foo.txt");//selbsterklärend
    char buffer[1024];//erwarte das keine Zeile grösser als 1024 ist
    while(leser::nächstezeile(buffer)){//wenn keine Zeile überig return false
    interpreter::interpretiere(buffer);}//selbsterklärend
    leser::schliess

    0
  • Mod

    alterbro schrieb:

    Ich frage ob dieses system Nachteile hat:

    Es hat zum Beispiel den dicken Nachteil, sich ohne Not auf 1024 Zeichen lange Zeilen zu beschränken.

    Es hat auch den Nachteil, erst Daten als Zeilen zu interpretieren, dann die Zeilen wieder als Daten zu interpretieren, wenn man in der Regel doch ganz ohne Umweg die Daten interpretieren könnte.

    0
  • ?

    ja, hat einen nachteil.
    zeilen mit mehr als 1024 bytes können nicht vollständig gelesen werden.

    0
  • A

    SeppJ schrieb:

    Es hat zum Beispiel den dicken Nachteil, sich ohne Not auf 1024 Zeichen lange Zeilen zu beschränken.

    wie meinst du das?

    SeppJ schrieb:

    Es hat auch den Nachteil, erst Daten als Zeilen zu interpretieren, dann die Zeilen wieder als Daten zu interpretieren, wenn man in der Regel doch ganz ohne Umweg die Daten interpretieren könnte.

    wie denn?

    0
  • ?

    alterbro schrieb:

    SeppJ schrieb:

    Es hat zum Beispiel den dicken Nachteil, sich ohne Not auf 1024 Zeichen lange Zeilen zu beschränken.

    wie meinst du das?

    SeppJ schrieb:

    ich wage es mir anzumaßen, dass er folgendes meint:
    für zeilen mit anzahl bytes > 1024 pro zeile kannst du dein programm in die tonne hauen.

    Es hat auch den Nachteil, erst Daten als Zeilen zu interpretieren, dann die Zeilen wieder als Daten zu interpretieren, wenn man in der Regel doch ganz ohne Umweg die Daten interpretieren könnte.

    wie denn?

    fscanf benutzen, z.b.

    0
  • Mod

    alterbro schrieb:

    SeppJ schrieb:

    Es hat zum Beispiel den dicken Nachteil, sich ohne Not auf 1024 Zeichen lange Zeilen zu beschränken.

    wie meinst du das?

    Gibt es (in C++) einen Grund, sich auf 1024 Zeichen zu beschränken? Nein. Höchstens in C und dort auch nur aus Bequemlichkeit, nicht wegen mangelnder Möglichkeiten. In C++ ist die Bequemlichkeit aber bei variabler Länge auch gegeben.

    SeppJ schrieb:

    Es hat auch den Nachteil, erst Daten als Zeilen zu interpretieren, dann die Zeilen wieder als Daten zu interpretieren, wenn man in der Regel doch ganz ohne Umweg die Daten interpretieren könnte.

    wie denn?

    Indem du das, was du mit der Zeile machst, direkt mit der Datei machst. Da du ja sicher die Dateninterpretation schön brav als Streamoperation implementiert hast, wie man es in C++ eben macht, sollte es keinen Unterschied machen, ob du einen fstream oder einen stringstream vorliegen hast.

    Und selbst in C würde man es nicht so machen, wie interpret0r richtig schreibt.

    0
  • ?

    SeppJ schrieb:

    Höchstens in C und dort auch nur aus Bequemlichkeit, nicht wegen mangelnder Möglichkeiten.

    Immer diese C-Basherei (den schlechtesten C-Code liest man hier im C++-Forum). In C ist die Bequemlichkeit mit getline auch gegeben. Trotzdem interpretiert man den Input oft gleich direkt vom FILE*.

    0
  • Mod

    unbash schrieb:

    In C ist die Bequemlichkeit mit getline auch gegeben.

    Fail.

    0
  • ?

    SeppJ schrieb:

    unbash schrieb:

    In C ist die Bequemlichkeit mit getline auch gegeben.

    Fail.

    ?

    char *line=NULL;
size_t bytes=0, len=0;
while (getline(&line, &len, stdin)>=0)
  bytes += len;
free(line);
printf ("%zu\n", bytes);

    vs

    std::ios_base::sync_with_stdio(false);
std::string s;
std::size_t bytes = 0;
while (std::getline(std::cin, s))
  bytes += s.size();
std::cout << bytes << '\n';

    Gleich bequemer Code und die C-Version ist erst noch schneller. Wo ist hier das Fail?

    0
  • Mod

    unbash schrieb:

    Wo ist hier das Fail?

    Es ist kein C.

    0
  • A

    Ok,danke, hat mir sehr geholfen

    0
  • I

    SeppJ schrieb:

    unbash schrieb:

    Wo ist hier das Fail?

    Es ist kein C.

    Doch:

    Since many programs interpret input on the basis of lines, it is convenient to have functions to read a line of text from a stream.

Standard C has functions to do this, but they aren't very safe: null characters and even (for gets) long lines can confuse them. So the GNU C Library provides the nonstandard getline function that makes it easy to read lines reliably.

    Ist aber nicht Standart-C, also irrelevant.

    EDIT: Warum wird das zensiert?

    0
  • B

    IrgendeinName schrieb:

    Ist aber nicht stan****-C, also irrelevant.

    EDIT: Warum wird das zensiert?

    Guck mal in den Duden.

    Edit:
    Oder auch hier:
    http://lexikon.martinvogel.de/standart.html

    0
  • Mod

    IrgendeinName schrieb:

    Ist aber nicht stan****-C, also irrelevant.

    EDIT: Warum wird das zensiert?

    Weil selbst das Forum erkennt, dass das eine dumme Aussage ist. Das ist unportables GNU-Zeugs, kein reines C. getline kann man im Linuxprogrammierungsforum als gescheite Antwort bringen, nicht in den ANSI-Sprachforen.

    Es ist ja nicht so, dass man für so ein getline jahrelange Erfahrung in der Entwicklung bräuchte, trotzdem sieht man kaum C-Code, in dem Funktionen dieser Art benutzt werden. Bequemlichkeit, denn ganz so trivial ist es nun einmal doch nicht.

    0
  • I

    Belli schrieb:

    IrgendeinName schrieb:

    Ist aber nicht stan****-C, also irrelevant.

    EDIT: Warum wird das zensiert?

    Guck mal in den Duden.

    Edit:
    Oder auch hier:
    http://lexikon.martinvogel.de/stan****.html

    Rechtschreibfehler zensieren? Obskure Methoden...

    SeppJ schrieb:

    Weil selbst das Forum erkennt, dass das eine dumme Aussage ist. Das ist unportables GNU-Zeugs, kein reines C. getline kann man im Linuxprogrammierungsforum als gescheite Antwort bringen, nicht in den ANSI-Sprachforen.

    Es ist ja nicht so, dass man für so ein getline jahrelange Erfahrung in der Entwicklung bräuchte, trotzdem sieht man kaum C-Code, in dem Funktionen dieser Art benutzt werden. Bequemlichkeit, denn ganz so trivial ist es nun einmal doch nicht.

    Ich habe selbst gesagt, das es nicht im Standard ist.

    Aber du hast Wort auf Wort gesagt, das die mit Link hinterlegte Funktion kein C sei, obwohl sie es ist. Sie ist nicht Standard C, aber C.

    Sie scheint das Problem des TE gelöst zu haben und ich glaube dem ist Portabilität recht egal.

    0
Anmelden zum Antworten