Textersetzungsprogramm funktioniert nicht



  • Hallo,
    ich muss ein Programm schreiben, dass alle # in einem Text entfernt, aber mein Programm braucht irgendwie ewig lang.
    Weiß vielleicht jemand wo der Fehöer liegt?

    #include <stdio.h>
    
    char dateiname[200];
    FILE *datei;
    FILE *datei2;
    char zeichen;
    main()
    {
        printf("Dateiname eingeben:");
        scanf("%s",dateiname);
        fflush(stdin);
        datei = fopen(dateiname,"r");
        datei2 = fopen("Datei_ohne_#.txt", "w");
        while (datei != EOF)
        {
            zeichen = fgetc(datei);
            if (zeichen == '#') continue;
            fputc(zeichen, datei2);
        }
        fclose(datei);
        fclose(datei2);
        return 0;
    }
    

    danke.



  • Die Abbruchbedingung deiner Schleife ist falsch.

    Aber selbst wenn sie richtig ist, ist das Prinzip falsch: Du prüfst, bevor der Fehler auftreten konnte.

    Aber was anderes: Womit lernst du C?



  • Ich habs in der Schule gelernt, hatte nur etwas in falscher Erinnerung.

    #include <stdio.h>
    
    char dateiname[200];
    FILE *datei;
    FILE *datei2;
    char zeichen;
    main()
    {
        printf("Dateiname eingeben:");
        scanf("%s",dateiname);
        fflush(stdin);
        datei = fopen(dateiname,"r");
        datei2 = fopen("Datei_ohne_#.txt", "w");
        while ((zeichen = fgetc(datei)) != EOF)
        {
            if (zeichen == '#') continue;
            fputc(zeichen, datei2);
        }
        fclose(datei);
        fclose(datei2);
        return 0;
    }
    

    Jetzt funktionierts, danke!



  • TorstenW schrieb:

    Ich habs in der Schule gelernt, hatte nur etwas in falscher Erinnerung.

    Wann war das? Vor 1989?
    Und globale Variablen haben sie dir da auch beigebracht?

    TorstenW schrieb:

    Jetzt funktionierts, danke!

    Nein, tut es nicht.
    EOF liegt außerhalb von char . zeichen muss daher ein int sein.



  • Nein dieses Jahr, erst seit ein paar Wochen.

    DirkB schrieb:

    Und globale Variablen haben sie dir da auch beigebracht?

    Man hat uns gesagt, dass diese dann überall verfügbar sind.



  • TorstenW schrieb:

    Nein dieses Jahr, erst seit ein paar Wochen.

    Seit 1989 gibt es einen genormten C-Standard, der auch noch ein paarmal ereitert wurde.

    Nur mal als Hinweis, was faslch ist:
    https://www.c-plusplus.net/forum/viewtopic.php?t=39346

    https://www.c-plusplus.net/forum/viewtopic.php?t=39349

    Das lässt Schlimmes für den Rest befürchten. 😞

    TorstenW schrieb:

    DirkB schrieb:

    Und globale Variablen haben sie dir da auch beigebracht?

    Man hat uns gesagt, dass diese dann überall verfügbar sind.

    Ja, das bedeutet global.
    Ist gefährlich, weil man sie von Überall ändern kann, und ist auch nicht nötig.



  • Ok werde ich abändern, danke.



  • außerdem solltest du nicht jedes Zeichen einzeln aus der Textdatei einlesen, das dauert zu lange, besser mit fgets o. Ä.

    Und dann kannst du mittels

    while(!feof(datei)
    {
    //einlesen
    //zeichen entfernen
    //schreiben
    }
    

    viel bequemer und übersichtlicher arbeiten



  • Quatsch.
    Ahnungslose Naivlinge sind wieder unterwegs.



  • HansKlaus schrieb:

    außerdem solltest du nicht jedes Zeichen einzeln aus der Textdatei einlesen, das dauert zu lange, besser mit fgets o. Ä.

    i.A sind die Ein-Ausgabefunktionen gepuffert. Und fgets leist aus dem selben Puffer wie fgetc .
    Wenn du da Performanceprobleme siehst, dann vergrößere den Puffer und/oder ändere das Verhalten mit setbuf oder setvbuf .

    Bei fgets sollte auch der Speicher für die Zeile groß genug sein. Da du das vorher nicht weißt, ist er meist zu groß oder auch zu klein.
    Diese Probleme hast du bei fgetc nicht.

    HansKlaus schrieb:

    while(!feof(datei)
    {
    //einlesen
    //zeichen entfernen
    //schreiben
    }
    

    Das ist der Gleiche Mist:

    DirkB schrieb:

    ..., ist das Prinzip falsch: Du prüfst, bevor der Fehler auftreten konnte.



  • Wutz schrieb:

    Quatsch.
    Ahnungslose Naivlinge sind wieder unterwegs.

    Wichtigtuer, die außer Stunk nichts beizutragen haben, sind wieder unterwegs. 😉

    DirkB schrieb:

    Bei fgets sollte auch der Speicher für die Zeile groß genug sein. Da du das vorher nicht weißt, ist er meist zu groß oder auch zu klein.
    Diese Probleme hast du bei fgetc nicht.

    da sehe ich in Zeiten von Arbeitsspeicher im Bereich größer 2GB eher kein Problem drin. 🙄
    Tatsache ist doch, dass jedes Mal eine Überprüfung stattfindet, ob eine Bedingung (nämlich das Dateiende) erfüllt ist, sprich bei 1 Mio Zeichen wird diese Überprüfung 1 Mio Male durchgeführt.

    Das ist der Gleiche Mist:

    DirkB schrieb:

    ..., ist das Prinzip falsch: Du prüfst, bevor der Fehler auftreten konnte.

    wieso? fgets hört mit dem Einlesen auf, wenn der Puffer voll ist oder das Dateiende erreicht ist, dann findet die Verarbeitung der Daten statt und dann wird die Schleife abgebrochen, wenn nix mehr zu holen ist.
    Oder wolltest du jetzt auf eine do-while-Schleife hinaus?



  • HansKlaus schrieb:

    da sehe ich in Zeiten von Arbeitsspeicher im Bereich größer 2GB eher kein Problem drin. 🙄

    Der Stack ist auch heute keine 2 GB groß.
    Wie groß soll das Array deiner Meinung nach sein?

    HansKlaus schrieb:

    Tatsache ist doch, dass jedes Mal eine Überprüfung stattfindet, ob eine Bedingung (nämlich das Dateiende) erfüllt ist, sprich bei 1 Mio Zeichen wird diese Überprüfung 1 Mio Male durchgeführt.

    fgets wird es intern auch nicht anders machen. Nebenbei prüft es noch auf '\n'.
    Aber auch dann ist fgets nicht das richtige Mittel sondern eher fread .
    Damit nutzt du das Array richtig aus.



  • DirkB schrieb:

    Wie groß soll das Array deiner Meinung nach sein?

    wenn mans genau machen will, ist das doch abhängig von der cpu, oder nicht?

    Aber auch dann ist fgets nicht das richtige Mittel sondern eher fread .
    Damit nutzt du das Array richtig aus.

    dann nehme ich das mit fgets zurück und erkläre, dass ich mich geirrt habe. 🙄


Log in to reply