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

• Jester01 veterán

  #4172

  #4170 nyunyu

  2013-08-16 22:04:09

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Jester01

  veterán

  #4170 nyunyu

  #4170 nyunyu

  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.

  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.

  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.

  Ezt nehezen hiszem, és ha tényleg így van az bug.
  Nekem egyébként működik linuxon, akár text akár binary módban nyitom meg a fájlt.

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