[C++] unsigned int a podanie znaku zamiast liczby

czesc wam,

mam pytanie dotyczące obiektu typu unsigned int. Jeżeli do takiego obiektu, zamiast liczby wpiszemy literkę - cin.good osiagnie status false.

Ale dlaczego później w cin.ignore, trzeba dawać:

cin.ignore(UINT_MAX, '\n'); [/code]

zamiast:

[code=php]cin.ignore(INT_MAX, ‘\n’); 

(jak w przypadku signed int :?:). Przecież jak wpiszemy do strumienia zamiast liczby 1 literkę - to kompilatorowi obojętne czy ma zignorować 2147483647 (INT_MAX) czy 4294967295 (UINT_MAX) liter (bo to ten argument oznacza w funkcji cin.ignore), bo i tak zaprzestanie ignorowanie po 1 literze (bo znajdzie ‘\n’).

Dlaczego więc ta róznica makr jest rozróżniana przez kompilator :?:

lepiej dawać:

cin.sync();

zamiast

cin.ignore(…);

Jeżeli już chcesz cin.ignore(…) to wystarczy podać cin.ignore(MAX_PATH,’\n’); (pod windows, no chyba że jest przekierowanie z pliku)

chodzi o to że program ma zignorować nie jedną literkę zaś cały wiersz, teoretycznie nawet UINT_MAX może być za mało.

cin.sync() - nie ma ograniczenia - wywali wszystko nawet jak będzie tego kilka terra.

#1

U mnie to makro wynosi 260 (i chyba u każdego, bo wątpie ze MS zrobił inne maksymalne dlugosci wiersza w konsoli na rózne systemy) - więc dużo mniej niż UINT_MAX :stuck_out_tongue:

#2

Tam na cplusplus jest napisane ze sync() jest do bufrowanego strumienia.

A o co chodzi z bufrowaniem w przypadku cin ? Bo w przypadku cout, jak strumień jest bufrowany, to tekst tam zgromadzony nie jest wypisywany co kazdą operację cout << costam, tylko jak nazbiera się tego tekstu dużo.

cin też jest buforowany - nawet jak chcesz wczytać jeden znak to i tak czeka na wprowadzenie całego wiersza.

… lub jak wejdzie endl, lub nastąpi wczytywanie z cin.

Tzn. naciśnięcia klawisza enter ?


[alex] a odnośnie tego MAX_PATH to jak wytłumaczysz, że jest to dużo mniejsza wartość od UINT_MAX :?:

Albo jeżeli wprowadzasz z klawiatury, ale jeżeli masz przekierowanie z pliku to o jakim naciśnięciu mowa?

MAX_PATH to maksymalna długość nazwy pliku a jednocześnie ograniczenie na długość wprowadzonego z klawiatury wiersza (o ile nie włączono /E). Nie ma co tu tłumaczyć.

No ogólnie chodziło mi o ‘\n’, więc z pliku też się przy tym zatrzyma (oczwyscie operator>> a nie inne funkcje). Już chyba rozumiem - czyli jak strumien jest bufrowany to sync zignoruje wszystko do znaku ‘\n’, a jak nie jest bufrowany to funkcja wg cplusplus.com wyrzuci błąd, bo nie będzie wiedziała kiedy przestać ?

Na ile mi wiadomo STL nie ma strumieni nie buforowanych, aczkolwiek na bazie istreram da się napisać strumień nie buforowany.

O jaki STL chodzi ? Bo Standard Template Library tu chyba nie pasuje :stuck_out_tongue:

Mi chodzi o bufrowanie/niebufrowanie strumienia za pomocą wrzucania do strumienia manipulatora unitbuf:

:arrow: http://cplusplus.com/reference/iostream … s/unitbuf/

Mylisz ostream z istream.

unitbuf - dla ostream.

brak buforowania które może spowodować błąd przy sync() - dla istream.

No wiem, że funkcji sync() chodzi o bufrowanie dla cinu. Myślalem tak jak mowiles, ze unitbuf dotyczy też cinu, a jednak nie…

Aha to skoro nie ma, to nie muszę się martwić o to, ze sync wywali błąd :slight_smile:

PS. STL, o które Ci chodziło to jednak Standard template library ? Nie wiedzialem ze ta nazwa oznacza całą bibliotekę standardową, a nie tylko klasy pojemnikowe typu vector…