Hirdetés

Új hozzászólás Aktív témák

  • nyunyu
    félisten

    Hogyan lehet _megbizhatoan_ lekerdezni, hanyadik karakternel tartunk az eppen feldolgozott fajlban, majd a lementett poziciora visszaugrani?

    ftell neha negativ erteket ad vissza, majd a kovetkezo karakter olvasasa utan az elozo rossz ertek+1-et, aztan fseek(fp, pos, SEEK_SET)-re total mashova ugrik, nem a "megjelolt" karakterhez.

    fgetpos paros is ugyanazokat az ertekeket adja vissza, mint az ftell.

    Ha manualisan szamolom a karaktereket minden getc/ungetc-nel, akkor sem pont oda ugrik vissza.

    Probaltam Win alatt VC++ 2010-zel, meg linux alatt GCC-vel, mindegyik produkalja.
    Feldolgozando fajl szoveget tartalmaz, mind win, mind linux stilusu sortores is elofordulhat benne.

    Bontsuk kette a problemat.

    Mint rajottem, az ftell/fgetpos csak akkor mukodik "helyesen", ha mar olvastam a streambol.
    Ha elso olvasas elott adom ki, akkor -20-at ad vissza, es innentol fogja egyesevel novelni/csokkenteni a poziciot minden getc/ungetc utan, nem nullatol.
    Ez a kisebbik problema.

    Nagyobbik bajom az, hogy a getc platform fuggoen kezeli a sorvege karaktereket.

    Pl. Visual C++ 2010 Win alatt ha \n karaktert lat, akkor lenyeli az utana jovo \r karaktert es mindig kettovel noveli a fajl poziciot.
    Ez azert problema, mert a feldolgozando forraskodok egy resze UNIX alatt lett mentve, ott meg nincsen \r az \n utan, de akkor is kettovel noveli a poziciot...

    Plusz nehezitesnek vannak olyan forraskodok is, amiben nincs \n, hanem \r-rel vannak tordelve. :DDD

    Probaltam szamolni, hany getc/ungetc-nel jarunk, de az sem ad pontos eredmenyt, mivel nem tudom eldonteni, hogy a latott \n karakternel eggyel vagy kettovel noveljem az indexet.
    Windows alatt automatikusan utana rakott \r egyaltalan nem jon at a getc-vel, nem tudom megszamolni.

Új hozzászólás Aktív témák