[c] Odczyt Z Pliku

[maybach]

Witam.

 

Otoz problem :-(

Jak odczytac z pliku tekstowego pewien ciag znakow, np. "Ala ma kota".

Jest to ciag, ktory zawiera biale znaki. Jak proboje go przeczytac, to fscanf odczytuje mi tylko pierwszy wyraz (do pierwszej spacji) czyli samo slowo "Ala".

Czy mozna tak zrobic, abym mogl sobie ustawic, aby odczytac ciag np. 15 znakow, nie zaleznie od tego czy zawiera spacje czy nie??

 

Pozdrawiam

[antrykot111]

  maybach napisał(a):

Witam.

 

Otoz problem :-(

Jak odczytac z pliku tekstowego pewien ciag znakow, np. "Ala ma kota".

Jest to ciag, ktory zawiera biale znaki. Jak proboje go przeczytac, to fscanf odczytuje mi tylko pierwszy wyraz (do pierwszej spacji) czyli samo slowo "Ala".

Czy mozna tak zrobic, abym mogl sobie ustawic, aby odczytac ciag np. 15 znakow, nie zaleznie od tego czy zawiera spacje czy nie??

 

Pozdrawiam

1650998[/snapback]

chyba tak:

char *buf = new char[100];HFILE file = fopen("file.txt","r");fread(buf,15,1,file);

Powinno śmigać :)

[Nargil]

albo:

const int rozmiar = 100;char *buf = new char[rozmiar+1];int i=0;FILE fp = fopen("plik.txt", "rb");while(fscanf(fp, "%c", &buf[i])>=0 && i<rozmiar) i++;

powyzszy przyklad odczytuje 100 bajtow pliku, lub mniej jesli plik sie skonczy szybciej :) Edytowane 15 Września 2005 przez Nargil

[sikor_soft]

ewentualnie otwierasz plik, czyta znak po znaku i porównuje z końcem wiersza (jeśli plik tekstowy i chodzi o cały wiersz - kod EOL <end of line>) - lub z końcem pliku (cały plik, kod EOF <End Of File>).

[enzo]

  antrykot111 napisał(a):

chyba tak:

char *buf = new char[100];HFILE file = fopen("file.txt","r");fread(buf,15,1,file);

Powinno śmigać :)

1651050[/snapback]

hym nie rozumiem czemu stosujesz funkcje do odczytywania danych binarnych skoro to jest plik tekstowy, dla ktorego jest inny zestaw funkcji.

 

ja bym to zrobil tak:

char bufor[100];FILE *plik;plik=fopen( "plik.txt", "r" );fgets( bufor,100,plik );

  sikor_soft napisał(a):

ewentualnie otwierasz plik, czyta znak po znaku i porównuje z końcem wiersza (jeśli plik tekstowy i chodzi o cały wiersz - kod EOL <end of line>) - lub z końcem pliku (cały plik, kod EOF <End Of File>).

jestes pewien ze w C jest taki kod jak EOL? bo ja o nim nie slyszalem (ale to moze byc tylko moja nie wiedza).

Edytowane 19 Września 2005 przez enzo

[antrykot111]

  enzo napisał(a):

hym nie rozumiem czemu stosujesz funkcje do odczytywania danych binarnych skoro to jest plik tekstowy,  dla ktorego jest inny zestaw funkcji.

 

ja bym to zrobil tak:

char bufor[100];FILE *plik;plik=fopen( "plik.txt", "r" );fgets( bufor,100,plik );

  sikor_soft napisał(a):

ewentualnie otwierasz plik, czyta znak po znaku i porównuje z końcem wiersza (jeśli plik tekstowy i chodzi o cały wiersz - kod EOL <end of line>) - lub z końcem pliku (cały plik, kod EOF <End Of File>).

jestes pewien ze w C jest taki kod jak EOL? bo ja o nim nie slyszalem (ale to moze byc tylko moja nie wiedza).

1657779[/snapback]

No fakt, dawno nie używałem tego do czytania plików :)

A kod EOL to chyba to samo co : '\r\n' ?

[Nargil]

napewno nie ma a przynajmniej nie do uzycia w funkcji czytajacej znak po znaku :) Bo \r\n to 2 bajty wiec niby jak on ma sprawdzic czy char c == "\r\n" ?

[Artur.M]

Nie jestem pewien ale mi się coś kojarzy że \r\n to przejście do nowej lini np. podczas zapisywania tekstu.

[Nargil]

a kto temu przeczy ? :D

[enzo]

@ Nargil

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

 

co do tej stalej EOL to jesli to jest \r\n to nie za bardzo mozna ja stosowac w plikach bo tam raczej nie wystepuje \r ( po co komu w pliku znak powrotu karetki? ). przynajmniej ja sie z tym nie spotkalem a przejscie do nowej linii bylo wykonywane tylko i wylacznie poprzez znak \n.

 

btw. jesli EOL to \r\n to oznaczalo by to ze najpierw znak karetki powraca na poczatek dopiero nastepnie nastepuje przejscie do nowej linii, czyli w sumie to przesunelibysmy biezaca linijke o jedna do dolu. (mam nadzieje ze za bardzo nie pobladzilem w moim rozumowaniu :/)

[antrykot111]

  enzo napisał(a):

@ Nargil

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

 

co do tej stalej EOL to jesli to jest \r\n to nie za bardzo mozna ja stosowac w plikach bo tam raczej nie wystepuje \r ( po co komu w pliku znak powrotu karetki? ). przynajmniej ja sie z tym nie spotkalem a przejscie do nowej linii bylo wykonywane tylko i wylacznie poprzez znak \n.

 

btw. jesli EOL to \r\n to oznaczalo by to ze najpierw znak karetki powraca na poczatek dopiero nastepnie nastepuje przejscie do nowej linii, czyli w sumie to przesunelibysmy biezaca linijke o jedna do dolu. (mam nadzieje ze za bardzo nie pobladzilem w moim rozumowaniu :/)

1658247[/snapback]

Jeśli zapisujesz na końcu samo '\n' to w notepadzie masz o ile mnie pamięc niemyli krzaka :)

Natomiast '\r\n' (nie pamiętam czy tak czy na odwrót r z n) pozwala notepadowi otworzyć poprawnie :)

Lepsz edytory (WordPad :wink: ) już sobie z tym radzą :)

[Polar]

Podczas zapisywania do pliku w trybie tekstowym każde wystąpienie znaku '\n' jest zastępowane '\r'+'\n' jeden za drugim. Podczas czytania jest odwrotnie i vice wersa.

Czyli prawidłowo przy odczycie lub zapisie powinno być samo '\n' lub '\r'+'\n'.

A bez sensu jest '\n'+'\r', bo samo \n jest przerabiane na '\n'+'\r' a my potem jeszcze dokładamy '\r'

Wychodzą bzdury w pliku bo tam '\r' nie istnieje.

[antrykot111]

  razor1 napisał(a):

Podczas zapisywania do pliku w trybie tekstowym każde wystąpienie znaku '\n' jest zastępowane '\r'+'\n' jeden za drugim. Podczas czytania jest odwrotnie i vice wersa.

Czyli prawidłowo przy odczycie lub zapisie powinno być samo '\n' lub '\r'+'\n'.

A bez sensu jest '\n'+'\r', bo samo \n jest przerabiane na '\n'+'\r' a my potem jeszcze dokładamy '\r'

Wychodzą bzdury w pliku bo tam '\r' nie istnieje.

1658390[/snapback]

A teraz zajażyłem czemu jestem w błędzie :wink:

Gdy jakiś czas temu robiłem HTML loggera zapisywałem text binarnie WriteFile czy tam _lwrite (nie pamiętam) i stąd to zamieszanie :)

Sory za wprowadzanie w błąd :unsure:

[sikor_soft]

  enzo napisał(a):

jestes pewien ze w C jest taki kod jak EOL? bo ja o nim nie slyszalem (ale to moze byc tylko moja nie wiedza).

1657779[/snapback]

Jedno nie przeczy drugiemu - zawsze możesz dać ifa po wykryciu jednego kodu... Nie pamiętam dokładnie struktury EOL, ale to da się sprawdzić.

[enzo]

ok doczytalem o EOL i dowiedzialem sie tego ze EOL pod winshitem to \r\n a pod linuxem to samo \n.

( ja programuje pod linuxem wiec zapewne dlatego nie spotkalem sie z kombinajcja \r\n, to tak dla sprostowania ;p )

[MeHow]

nargil, to powinno byc tak:

   const int rozmiar = 100;    char buf[rozmiar+1];    int i=0;    FILE *fp;    fp = fopen("test.txt", "r");    while(fscanf(fp, "%c", &buf[i])>=0 && i<rozmiar) i++;

a nie tak jak napisales. Skad Ci sie "new" wzielo w C ?

[maybach]

dzieki ludzie za te wszystkie pomoce, ale znalazlem jeszcze jedna funkcje:

 

char *fgets(char *s, size_t n, FILE *stream);

 

pod zmienna 'n' podaje liczbe znakow do odczytania.

 

Nie trzeba czytac znak po znaku.

[enzo]

  maybach napisał(a):

dzieki ludzie za te wszystkie pomoce, ale znalazlem jeszcze jedna funkcje:

 

char *fgets(char *s, size_t n, FILE *stream);

 

pod zmienna 'n' podaje liczbe znakow do odczytania.

 

Nie trzeba czytac znak po znaku.

1661844[/snapback]

eh widac ze nie czytasz uwaznie tego co ci inni odpisuja. kilka postow wyzej podalem ci przyklad z urzyciem tej funkcji. :mur:

[sikor_soft]

  maybach napisał(a):

dzieki ludzie za te wszystkie pomoce, ale znalazlem jeszcze jedna funkcje:

 

char *fgets(char *s, size_t n, FILE *stream);

 

pod zmienna 'n' podaje liczbe znakow do odczytania.

 

Nie trzeba czytac znak po znaku.

1661844[/snapback]

O.K. - ale co zrobisz, gdy tekst jest długi i nie znasz go wcześniej? Szukana fraza jest podawana przez użytkownika, plik to powiedzmy encyklopedia w formie tekstu?

Znając położenie szukanego tekstu i mając krótki plik - nie ma sprawy, ale w dłuższym pliku to już może być problem. Przyupuszczam, że kolejnym zadaniem (pewnie to było na zaliczenie) będzie porównanie tekstów w kilku plikach (albo sprawdzenie, czy dana fraza znajduje się w kilku różnych plikach), więc wtedy i tak musisz porównać, chociaż oczywiście metoda znak po znaku jest dość wolna... Zawsze można skorzystać z innych funkcji - a jakich, to już pozostawiam dociekliwym ;)

[KrzychuG]

  sikor_soft napisał(a):

O.K. - ale co zrobisz, gdy tekst jest długi i nie znasz go wcześniej? Szukana fraza jest podawana przez użytkownika, plik to powiedzmy encyklopedia w formie tekstu?

1662256[/snapback]

Odczytujesz go linia po linii (tak shematycznie):

 

f = fopen("pliczek", "r");while (!feof(f)) {  fgets(blah, 1023, f);  parse_data(blah);}

[mina86]

  "maybach" napisał(a):

Czy mozna tak zrobic, abym mogl sobie ustawic, aby odczytac ciag np. 15 znakow, nie zaleznie od tego czy zawiera spacje czy nie??

Poczaruj sobie z fscanf("%15c", string). Pamiętaj jednak żeby zawczasu zmienną string wypełnić zerami bo %c nie zapisuje kończącego znaku NUL ('\0').

 

  "enzo" napisał(a):

hym nie rozumiem czemu stosujesz funkcje do odczytywania danych binarnych skoro to jest plik tekstowy, dla ktorego jest inny zestaw funkcji.

A ja nie rozumiem czemu nie. :)

 

  "antrykot111" napisał(a):

A kod EOL to chyba to samo co : '\r\n' ?

To zależy w jakim formacie plik został zapisany. W Windowsie, DOS-ie i takich tam EOL to "\r\n". W uniksach to '\n', a na Macach jeszcze coś innego (już dokładnie nie pamiętam czy to jest '\r' czy '\n\r').

 

  "Nargil" napisał(a):

napewno nie ma a przynajmniej nie do uzycia w funkcji czytajacej znak po znaku :) Bo \r\n to 2 bajty wiec niby jak on ma sprawdzic czy char c == "\r\n" ?

Należy sprawdzać czy c == '\n'.

 

  "enzo" napisał(a):

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

Muahahahahaha.. Dobry joke ;) Owszem, zwraca inty, ale przyjmują one jedynie wartości od 0 do 255 jeżeli odczytano znak lub EOF (najczęściej -1) gdy napotkano na koniec pliku.

 

  "enzo" napisał(a):

o do tej stalej EOL to jesli to jest \r\n to nie za bardzo mozna ja stosowac w plikach bo tam raczej nie wystepuje \r ( po co komu w pliku znak powrotu karetki? ). przynajmniej ja sie z tym nie spotkalem a przejscie do nowej linii bylo wykonywane tylko i wylacznie poprzez znak \n.

A przyglądałeś się dokładnie jakiemuś plikowi zapisanemu pod Windowsem? Chyba nie :)

 

  "enzo" napisał(a):

btw. jesli EOL to \r\n to oznaczalo by to ze najpierw znak karetki powraca na poczatek dopiero nastepnie nastepuje przejscie do nowej linii, czyli w sumie to przesunelibysmy biezaca linijke o jedna do dolu. (mam nadzieje ze za bardzo nie pobladzilem w moim rozumowaniu :/)

Nie, bo '\n' to new line, a nie jakieś move line to next line czy cokolwiek innego. '\n' jedynie przesuwa karetkę w dół.

 

  "antrykot111" napisał(a):

Jeśli zapisujesz na końcu samo '\n' to w notepadzie masz o ile mnie pamięc niemyli krzaka :)

Tutaj mogę się mylić, ale wydaje mi się, że w nowszych notepadach to poprawili zlekka.

 

  "KrzychuG" napisał(a):

Odczytujesz go linia po linii

A co jak linia ma np. 100 tysięcy znakow? Sposób z fgets() w takich wypadkach może nie zadziałać. Osobiście bym coś takiego robił odczytując plik na zmianę do 2 buforów, żeby móc sprawdzać czy dany tekst występuje, w którymś z odczytanych fragmentów lub na granicy obu buforów.

[antrykot111]

  Cytat

Tutaj mogę się mylić, ale wydaje mi się, że w nowszych notepadach to poprawili zlekka.

Mam XPeka i sie dośćdługo zastanwiałem czemu wywala krzaka :) Dopiero potem na forum powiedziano mi że ma być \r\n a nie samo \n :)

Ale WordPad i reszta wypaśniejszychedytorków już sobie radzi :)

[enzo]

  mina86 napisał(a):

  enzo napisał(a):

 

hym nie rozumiem czemu stosujesz funkcje do odczytywania danych binarnych skoro to jest plik tekstowy, dla ktorego jest inny zestaw funkcji.

A ja nie rozumiem czemu nie. icon_smile3.gif

 

chociazby dlatego ze jak chlopak stawia dopiero piersze kroki w C i zacznie mieszac rozne funkcje przeznaczone do czego innego to moze pozniej miec przez to problemy przy pisaniu jakis innych progsow. takie mieszanie funkcji moze prowadzic czasami do niepotrzebnych bledow.

 

  mina86 napisał(a):

  enzo napisał(a):

 

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

Muahahahahaha.. Dobry joke icon_wink2.gif Owszem, zwraca inty, ale przyjmują one jedynie wartości od 0 do 255 jeżeli odczytano znak lub EOF (najczęściej -1) gdy napotkano na koniec pliku.

 

hym... wlasnie sam sobie zaprzeczyles. napisales ze wartosci zwracane przez te funkcje przyjmuja wartosci od 0 do 255 (zreszta w zmiennej typu char tez mozna zapisywac tylko wartosci z tego przedzialu) a EOF najczesciej przyjmuje -1 wiec logicznie rozumujac -1 nie powinno byc zapisywane w zmiennej znakowej bo ta moze przyjmowac warosci tylko z zakresu 0-255 a -1 znajduje sie ponizej tej granicy.

 

przytocze jeszcze cytat z ksiazki helionu "Jezyk C. Wskazniki. Vademecum profesjonalisty"

  Cytat

Czesto zadawanym pytaniem jest: dlaczego zmienna zn jest zadeklarowana jako int, choc jest uzywana do odczytu znakow? odpowiedz na nie brzmi: pozniewaz EOF jest wartoscia calkowita, ktora wymaga wiecej bitow niz jest dostepne w zmiennej znakowej; pozwala to zapobiegac przypadkowej interpretacji odczytanego znaku jako warosci EOF. Ale oznacza to rowniez, ze zmienna zn, ktora jest uzywana do odczytywania znakow, musi byc na tyle szeroka, aby mogla przechowywac rowniez wartosc EOF, i dlatego stosujemy wartosc calkowita.

  mina86 napisał(a):

  enzo napisał(a):

 

o do tej stalej EOL to jesli to jest \r\n to nie za bardzo mozna ja stosowac w plikach bo tam raczej nie wystepuje \r ( po co komu w pliku znak powrotu karetki? ). przynajmniej ja sie z tym nie spotkalem a przejscie do nowej linii bylo wykonywane tylko i wylacznie poprzez znak \n.

A przyglądałeś się dokładnie jakiemuś plikowi zapisanemu pod Windowsem? Chyba nie icon_smile3.gif

 

czytaj uwazniej!!!

 

  enzo napisał(a):

ok doczytalem o EOL i dowiedzialem sie tego ze EOL pod winshitem to \r\n a pod linuxem to samo \n.

( ja programuje pod linuxem wiec zapewne dlatego nie spotkalem sie z kombinajcja \r\n, to tak dla sprostowania ;p )

to bylo napisane kilka postow nizej. :blink:

 

  mina86 napisał(a):

  enzo napisał(a):

 

btw. jesli EOL to \r\n to oznaczalo by to ze najpierw znak karetki powraca na poczatek dopiero nastepnie nastepuje przejscie do nowej linii, czyli w sumie to przesunelibysmy biezaca linijke o jedna do dolu. (mam nadzieje ze za bardzo nie pobladzilem w moim rozumowaniu :/)

Nie, bo '\n' to new line, a nie jakieś move line to next line czy cokolwiek innego. '\n' jedynie przesuwa karetkę w dół.

 

oops moj blad. thx za wyjasnienie.

 

P.S. ty to ten mina86 z forum.slackware.pl ?

Edytowane 23 Września 2005 przez enzo

[mina86]

  enzo napisał(a):

chociazby dlatego ze jak chlopak stawia dopiero piersze kroki w C i zacznie mieszac rozne funkcje przeznaczone do czego innego to moze pozniej miec przez to problemy przy pisaniu jakis innych progsow.

Przyznaję, jest to pewien argument.

 

  enzo napisał(a):

hym... wlasnie sam sobie zaprzeczyles.

Przeanalizujmy całą wymianę zdań:

 

  Nargil napisał(a):

napewno nie ma a przynajmniej nie do uzycia w funkcji czytajacej znak po znaku  Bo \r\n to 2 bajty wiec niby jak on ma sprawdzic czy char c == "\r\n" ?

  enzo napisał(a):

@ Nargil

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

Z tych dwóch wypowiedzi wyciągnąć należy wniosek, jakoby EOL miał 2 bajty (konkretnie "\r\n"[1]), a przy pomocy getchar() można porównać czy odczytany znak (?!) to "\r\n"... Chyba przyznasz, że to nie prawda?

 

  enzo napisał(a):

zreszta w zmiennej typu char tez mozna zapisywac tylko wartosci z tego przedzialu

Gwoli ścisłości, to zależy od ustawień kompilatora - zazwyczaj char jest zmeinną ze znakiem, a więc można w nim przechowywać wartości z przedziału: -128..127.

 

  enzo napisał(a):

to bylo napisane kilka postow nizej.

Wybacz lenistwo, ale gdy do tego doczytałem to już nie chciało mi się poprawiać ;)

 

  enzo napisał(a):

P.S. ty to ten mina86 z forum.slackware.pl ?

Owszem.

 

[1] chociaż tak prawdę mówiąc "\r\n" to w C 3 bajty: '\r' (CR), '\n' (NL) i '\0' (NUL).

[enzo]

widze ze to ja nie dopilnowalem pewnych szczegolow no ale nic teraz postaram sie to naprawic.

a wiec zacznijmy pokolei

 

  enzo napisał(a):

hym... wlasnie sam sobie zaprzeczyles.

tutaj chodzilo mi o to ze chcesz zapisac wartosc -1 w zmiennej operujacej na liczbach z zakresu 0-255.

 

  mina86 napisał(a):

Gwoli ścisłości, to zależy od ustawień kompilatora - zazwyczaj char jest zmeinną ze znakiem, a więc można w nim przechowywać wartości z przedziału: -128..127.

oczywiscie ze tak. ja przyjolem zalozenie ze jesli mowimy w tym topicu o char'ach to w rzeczywistosci chodzi nam o typ unsigned char.

 

  mina86 napisał(a):

Z tych dwóch wypowiedzi wyciągnąć należy wniosek, jakoby EOL miał 2 bajty (konkretnie "\r\n"[1]), a przy pomocy getchar() można porównać czy odczytany znak (?!) to "\r\n"... Chyba przyznasz, że to nie prawda?

no i tutaj musze sie przyznac do drobnego (a moze i nie tak calkiem drobnego) przeoczenia, a mianowicie tak bardzo skoncentorwalem sie na miejscu zajmowanym przez EOL w pamieci ze nie zauwazylem ze w pliku moze byc reprezentowana przez wiecej niz jeden znak.

ok teraz przejdzmy do getchar().

przyznaje ze za pomoca tej funkcji nie mozna wykonac porownania do \r\n gdyz sa to dwa znaki.

 

  mina86 napisał(a):

[1] chociaż tak prawdę mówiąc "\r\n" to w C 3 bajty: '\r' (CR), '\n' (NL) i '\0' (NUL).

hym, chodzi ci o to ze EOL to ciag \r\n\0 ?

[antrykot111]

mina86: Czy jesteś pewien że EOL ma na końcu 0 ?

Właściwie po co ono ma tam być. W stringu w pamięci jest po to aby było widomo gdzi sie kończy. Ale po co on ma być w pliku ?

[Nargil]

EOL nie ma \0 na koncu... lol, ale sie dyskusja rozwinela :) a co do NEW w moim przykladzie to fakt przeoczenie :) Juz poprawiam

 

const int rozmiar = 100;char *buf = (char*)malloc(rozmiar+1);int i=0;FILE fp = fopen("plik.txt", "rb");while(fscanf(fp, "%c", &buf[i])>=0 && i<rozmiar) i++;

oczywiscie za pomoca fseek i ftell mozemy odczytac rozmiar pliku i ustawic odpowiednio zmienna rozmiar, a nastepnie skozystac z rewind :)

 

mina86 napisal: Należy sprawdzać czy c == '\n'.

 

ja nie twierdze ze tak sie nie robi, ale po co miec smiecia \r w linii ? Ja bym porownywal \r i przeskakiwal o 1 byte dalej do przodu ( omijajac \n )

[Polar]

No dobra uściślijmy nieco:

 

1. W programie

'\n' ma jeden bajt, bo to pojedynczy znak

"\n" ma 2 bajty, bo dochodzi tu znak końca stringu

"\r\n" ma 3 bajty, bo tu też dochodzi znak końca stringu

Chodzi tu tylko o program i cała teorię napisów "..." i '.', co wcale nie oznacza że w pliku jest tak samo.

 

2. Pliki

KAŻDY ZNAK '\n' lub "\n" napotkany przy zapisie do pliku jest zmieniany w na 2 znaki '\r'+'\n' które ZAWSZE!!! kończą linię tekstu w pliku tekstowym.

A przy odczycie pliku każde wystąpienie znaku '\r'+'\n' jest zmieniane na znak '\n' , który to znak trafia do programu.

 

I TU JEST UKRYTA CAŁA TAJEMNICA z rozmiarem i możliwością porównań znaków odczytanych z pliku a znaków w programie. Bez tych ukrytych zmian nie można by było tak prosto robić róznych rzeczy.

 

Najlepej jest zachować zasadę że przy zapisie do pliku tekstowego chcąc zejśc linie niżej uzywamy ( andl lub '\n' lub "\n" ) te 3 znaki są traktowane tam samo przy zapisie do pliku, mimo że w programie jest/może być inaczej.

[mina86]

  enzo napisał(a):

tutaj chodzilo mi o to ze chcesz zapisac wartosc -1 w zmiennej operujacej na liczbach z zakresu 0-255.

Ależ ja nic takiego nie chcę czynić. Opisałem jedynie co zwraca funkcja getchar()

 

  enzo napisał(a):

hym, chodzi ci o to ze EOL to ciag \r\n\0 ?

Nie, jedynie stwierdzam, że w C/C++ zapis: "\r\n" to są 3 bajty. Ma to luźne powiązanie z właściwym tematem tego wątku.

 

  Nargil napisał(a):

ja nie twierdze ze tak sie nie robi, ale po co miec smiecia \r w linii ? Ja bym porownywal \r i przeskakiwal o 1 byte dalej do przodu ( omijajac \n )

To może w niekórych przypadkach nie zadziałać poprawnie. Pierwsze co mi przychodzi do głowy to gdybyś chciał operować na wyjściu jakiegoś programu, który faktycznie używa '\r' do powrotu na początek linii (żeby ją potem czymś nadpisać).

 

Poza tym, wydaje mi się, że w przypadku otwierania pliku w trybie tekstowym (tj. nie binarnym) biblioteka sama dokonuje konwersji pomiędzy "\r\n" a '\n'.

Edytowane 26 Września 2005 przez mina86

[enzo]

ok wyjasnijmy wszystko dokladnie

 

  mina86 napisał(a):

  enzo napisał(a):

 

to ze ta stala ma 2 bajty nic nie przekresla, bo np EOF tez ma wiecej niz 1 bajt. jakbys sie dokladnie przyjrzal prototypom funkcji znakowego wejsci-wyjscia zauwazylbys ze one zwracaja int'y. dlatego jesli zczytuje sie znaki z pliku nalezy kozystac nie z char'ow tylko z int'ow.

Muahahahahaha.. Dobry joke icon_wink2.gif Owszem, zwraca inty, ale przyjmują one jedynie wartości od 0 do 255 jeżeli odczytano znak lub EOF (najczęściej -1) gdy napotkano na koniec pliku.

 

no i jedziemy z koksem, a wiec zapewne zle zrozumiales o co mi chodzilo w tej mojej wypowiedzi co jest wina mojego gapiostwa (i marnej znajomosci polskiego ;p). chyba pomyslales sobie ze nalezy stosowac int'y bo funkcje znakowego wejscia-wyjscia zwracaja wlasnie int'y. a mi chodzilo o to ze nalezy sotoswac int'y bo niektore stale takie jak EOF nie moga byc zapisane w zmiennej typu char.

nastepnie twoja wypowiedz nakierowala moj tok rozumowania tak ze wydawalo mi sie ze nie wierzysz ze stalej EOF nie mozna zapisac w zmiennej typu char co z kolej pchnelo mnie do napisania:

  enzo napisał(a):

hym... wlasnie sam sobie zaprzeczyles.

oraz pozniej:

  enzo napisał(a):

tutaj chodzilo mi o to ze chcesz zapisac wartosc -1 w zmiennej operujacej na liczbach z zakresu 0-255.

a wiec przyznaje sie do bledow bez bicia ;p

no i nie ma tego zlego co by na dobre nie wyszlo. :]