Problem beim zeichenweisen auslesen einer Textdatei

filzstift

Hallo zusammen,
ich versuche derzeit einfach eine Textdatei komplett auszulesen, und zwar mit folgendem Code:

FILE *vfs = fopen(filename,"r");
  if(vfs == NULL){
    printf("Datei nicht gefunden\n");
    return 2;
  } else {
    int puffer;
    while((puffer = fgetc(vfs)) != EOF){
         printf("%c",puffer);
    }
    printf("\n");
    fclose(vfs);
    return 0;
  }

Das dürfte ja eigentlich nicht so schwer sein, aber ich bekomme komischerweise nur solche Zeichen ausgegeben "nǩ�+7u.�i". Ist wohl irgendwie eine falsche Kodierung. Ich würde mich freuen wenn mir da jemand auf die Sprünge helfen könnte

SeppJ

Dann wird das wohl das sein, was in der Datei steht. Welche andere Ausgabe hättest du denn stattdessen erwartet und warum?

filzstift

Oh man, ich hatte wirklich nur die falsche Dateiendung angehängt, sodass eine andere Datei geöffnet wurde.. Sorry Das kam mir aber auch schon so komisch vor, weil das ja eigentlich funktionieren musste.

SeppJ

Noch ein allgemeiner Hinweis: printf für einzelne chars ist Kanonen auf Spatzen. Dazu gibt es putchar/(f)putc.

Das gilt, auch wenn es hier nicht vorkommt, ebenso für Zeichenketten, für die es (f)puts gibt. (Ganz schlimm wäre es, eine nutzerdefinierte Zeichenkette direkt mit printf auszugeben, anstatt über einen Formatstring mit %s.)

printf ist eher für Zahlen und komplexe Formatstrings da.

SeppJ schrieb:

Noch ein allgemeiner Hinweis: printf für einzelne chars ist Kanonen auf Spatzen. Dazu gibt es putchar/(f)putc.

printf ist ein Compiler-Intrinsic und deratig optimiert, dass das hier performancemässig kein Unterschied macht.

printf("%s\n",s) wird zu puts(s) umgewandelt, printf("%c") zu putchar etc. Einfach mal den Output vom GCC anschauen. Daher macht es nichts, printf für alles zu verwenden.

SeppJ

Finde ich nicht gut. So lernt man, sich auf den Compiler zu verlassen, anstatt darüber nachzudenken, was man warum tut.
Ich finde aber gut, dass der GCC das optimieren kann. Um auf den vorherigen Kritikpunkt zurück zu kommen: Können alle (gängigen) Compiler das? Auch, wenn (wie so oft ) printf nur implizit deklariert wurde?

Wutz

grosserzeh schrieb:

printf ist ein Compiler-Intrinsic und deratig optimiert, dass das hier performancemässig kein Unterschied macht.

Quatsch.
Das ist schon deswegen totaler Schwachsinn, da die Rückgabewerte standardgemäß nicht inhaltlich übereinstimmen müssen.

Wutz

SeppJ schrieb:

Können alle (gängigen) Compiler das?

Natürlich können sie das nicht. Das weißt du auch selbst.
Vielleicht verwechselt der genannte Herr die Ersetzung das ja mit printf >> fprintf(stdout,

SeppJ

Wutz schrieb:

SeppJ schrieb:

Können alle (gängigen) Compiler das?

Natürlich können sie das nicht.

Lass mir doch meine rhetorischen Fragen :p .

An sich kann der GCC das jedoch. Das stimmt schon. Es ist halt sehr fragil; schon printf("%s", x) wird nicht mehr zu fputs(x, stdout) optimiert. Und sobald man den Rückgabewert auswertet, ist natürlich auch nichts mehr zu retten.

Hier hat das mal jemand systematisch "erforscht":
http://www.ciselant.de/projects/gcc_printf/gcc_printf.html

SeppJ schrieb:

Finde ich nicht gut. So lernt man, sich auf den Compiler zu verlassen, anstatt darüber nachzudenken, was man warum tut.

Ach so, bist du einer, der >>1 schreibt anstatt /2 ? Zumindest empfiehlst du das gerade.

Ich finde man soll sich als Anfänger lieber auf den Compiler verlassen und dann später kontrollieren, ob der Compiler wirklich das macht, was er sollte.

Und ja, andere Compiler (Clang...) können das auch.

SeppJ

grosserzeh schrieb:

SeppJ schrieb:

Finde ich nicht gut. So lernt man, sich auf den Compiler zu verlassen, anstatt darüber nachzudenken, was man warum tut.

Ach so, bist du einer, der >>1 schreibt anstatt /2 ? Zumindest empfiehlst du das gerade.

Nö, absolut nicht. Wir sprechen hier von keiner Microoptimierung im Assembler, sondern von einem komplett falschen Vorgehen. printf ist nicht gedacht für einzelne Zeichen und Zeichenketten, es ist falsch, es hier zu benutzen. /2 ist hingegen dafür gedacht, Zahlen durch 2 zu teilen.

P.S.: Und MSVC kann es wohl nicht, kann jedenfalls nichts dazu finden. Also schon einmal einer der verbreitetsten Compiler, die das nicht können.