Wpis z mikrobloga

#programowanie #problem
C++
W moim programie tworzę klasę Liga i klasę Zespol
W konstruktorze Liga podaję ilość drużyn, następnie w pętli for tworzony jest obiekt Zespol i dodawany na koniec tabeli za pomocą biblioteki vector (tablica.push_back(nowyzespol); )
Podczas tworzenia obiektu Zespol wywoluje się jego konstruktor ustalający wartość string nazwa

tu jest ten problem
gdy w kodzie mam cin >> nazwa; to przy podaniu nazwy zespołu np. Wisła Kraków to robią się 2 obiekty zespół, jeden z nazwa=Wisła a drugi nazwa=Kraków (co jest logiczne)
a gdy zmieniam cin>> na getline (cin, nazwa); co powinno być lekarstwem, to pierwszy obiekt tworzy się bez nazwy, dopiero od drugiego mogę wpisywać nazwę

o co chodzi??
Pobierz ZohanTSW - #programowanie #problem
C++
W moim programie tworzę klasę Liga i klasę Z...
źródło: comment_9knLClUImnba6wPBI3JypyEjgTFQ0SC9.jpg
  • 18
@Vokil: @ZohanTSW: fflush to średnie rozwiązanie, bo jego działanie nie jest ustandaryzowane w takim przypadku.

If the given stream was open for writing (...)

If stream is a null pointer (...)

In all other cases, the behavior depends on the specific library implementation. In some implementations, flushing a stream open for reading causes its input buffer to be cleared (but this is not portable expected behavior).


http://www.cplusplus.com/reference/cstdio/fflush/

Dodatkowo, mieszanie
@frax: @Kaczus2B: ale działa mi to póki co, spodziewam się, że może coś nie pyknąć gdybym chciał rozwinąć nieco program. Ale tym się teraz nie chcę martwić, najpierw mój projekt minimum, potem zajmę się ulepszaniem kodu
@Kaczus2B: To jest ten sam strumień, tylko że iostream (cin) i stdio mogą mieć potencjalnie niezależne buforowanie - ale domyślnie są zsynchronizowane, więc to nie jest problem. Natomiast jak napisałem wyżej - samo fflush w tym kontekście jest nieprzenośne w ogóle, a poza tym zachowanie buforowania też może być teoretycznie różne.
@Kaczus2B: Wydaje mi się, że nie da się odpiąć cin od stdin, więc to jednak jest ten sam stream, mimo, że przez ios_base::sync_with_stdio(false) można wyłączyć wspólne buforowanie. Nadal chyba jednak wywołanie freopen() na stdin wpływa na cin (nie sprawdzałem, dokumentacja którą widziałem nie wyjaśnia tego zupełnie jednoznacznie, ale to by raczej było rozsądne).

W każdym razie, dopóki nie wyłączy się synchronizacji, to użycie fflush powinno tak samo działać na stdin
@Kaczus2B: Ale ogólnie mieszanie stdio z iostream jest niezbyt zdrowe, bo mało czytelne. No i stdio nie jest dobrze typowane, i ma funkcje grożące buffer overflow - tylko że ma printfa, który jest wygodny :P
@frax: To zależy od implementacji biblioteki standardowej, tak może być, ale nie musi. A skoro nie musi, to zakładanie, że skoro tak było w wielu przypadkach, nie znaczy, że jutro z innym kompilatorem, albo inna biblioteką standardową (kompilator może miec kilka implementacji) też tak będzie. To coś jak przykładowe zadanie z testów, które opisałem, albo sztuczki niektórych z czasów dosa, że zwalniali pamięć, a później czytali wyniki pod adresami, gdzie
@Kaczus2B: Wiesz co, nie będę teraz tego sprawdzał super dokładnie, ale wydaje mi się, że specyfikacja naprawdę nie pozwala na odpięcie cin od stdin, i że to nie zależy od implementacji - zwłaszcza, dopóki jest włączona synchronizacja z stdio (a domyślnie jest).

A parzystość sprawdza się przez (n % 2) użyte jako bool, bez porównania z 1, zamiast używać abs() :)

Za to trochę mnie zaskoczyło, że char s[] =
@Kaczus2B: O, fajny pomysł z INT_MAX, nie pomyślałbym o tym.

Swoją drogą, w praktycznych zastosowaniach lepsze może być wczytanie tego po prostu getlinem, żeby móc sprawdzić, czy nie ma tam jakichś śmieci.