Стани std::cin: good/eof/fail/bad

1. Вступ

Коли новачок пише std::cin >> n;, він часто сприймає це як магічне заклинання: «Введіть число, будь ласка». Але std::cin не телепат і не психолог. Він виконує лише одну чесну дію: намагається витягти дані потрібного формату з потоку введення. Якщо це не вдається, він фіксує проблему у внутрішньому стані. А далі починається важливе: цей стан впливає на всі наступні операції читання.

Якщо уявити std::cin як касира, то оператор >> — це спроба «зчитати штрихкод». Якщо штрихкоду немає, тобто замість цифр — літери, касир не вгадує ціну за настроєм. Він каже: «Не можу», засвічується індикатор помилки — і доки ви не розвʼяжете проблему, каса не продовжить нормально працювати.

Технічний нюанс: потоки введення й виведення в C++ реалізовані як шаблонні класи (basic_istream, basic_ostream тощо), а звичний std::cin — це конкретний обʼєкт для char‑потоку. Для сьогоднішньої практики це не критично, але знати корисно: «istream» — це сімейство типів, а не один «чарівний клас».

Прапорці стану потоку: good/eof/fail/bad

Коли ми говоримо «стан std::cin», то маємо на увазі набір внутрішніх прапорців. Їх можна перевіряти методами good(), eof(), fail(), bad(). Ці методи нічого не «лагодять» — вони лише чесно показують, у якому режимі зараз перебуває потік.

Найзручніше думати так: стан потоку — це причина, чому ми зараз можемо або не можемо продовжувати читання.

cin.good()

cin.eof()

cin.fail()

cin.bad()

Важливо не переплутати: good() — це не окрема «суперістина», а радше стан «немає прапорців помилок». На практиці good() використовують рідше, бо зручніше мислити так: «якщо вдалося прочитати — працюємо», а не «якщо потік у хорошому стані — спробуймо прочитати».

2. Читання з перевіркою: if (std::cin >> x)

Один із найважливіших прийомів у C++ має такий вигляд:

#include <iostream>

int main() {
    int n = 0;

    if (std::cin >> n) {
        std::cout << "n = " << n << '\n';   // наприклад: n = 42
    } else {
        std::cout << "Input failed\n";      // Input failed
    }
}

Тут немає жодного «дивного трюку», якщо бодай раз розібратися, як це працює.

Вираз std::cin >> n повертає потік за посиланням. А потік уміє перетворюватися на bool — у сенсі «я зараз у нормальному стані чи ні?». Тому if (std::cin >> n) читається так: «Спробуй прочитати n. Якщо вдалося — виконуй першу гілку».

Цей запис зручний тим, що не дає вам випадково використати сміття. Якщо читання не вдалося, змінна може залишитися зі старим значенням, і використовувати її без перевірки — логічна помилка.

Чому «змінна все одно має якесь значення» — погана новина

Психологічно легко потрапити в пастку: «ну x ж якось вивівся, отже, прочитався». Але в C++ фраза «змінна вивелася» означає лише те, що в ній зберігається якесь значення. А звідки воно взялося — це вже ваша відповідальність.

Небезпечний приклад:

#include <iostream>

int main() {
    int n = 100;            // припустімо, у нас є значення за замовчуванням
    std::cin >> n;          // якщо введення некоректне, n може лишитися 100

    std::cout << "n=" << n << '\n'; // n=100 (навіть якщо ввели "oops")
}

Якщо користувач уведе oops, виведення може бути n=100. І новачкові може здатися: «о, працює!». А потім ця «сотня» раптом бере участь у розрахунку знижки, довжини масиву, розміру вектора чи кількості ітерацій циклу — і починається цирк.

Ідея проста: не довіряйте значенню змінної, доки не перевірили, чи читання було успішним.

3. fail() і «залипання» після помилки формату

Найчастіша причина фрази «моя програма зависла» у новачків — це failbit, тобто стан fail().

Уявімо, що ви очікуєте число:

• введення: 10 — чудово
• введення: abc — це вже не число

У другому випадку потік не може витягти int. Що він робить?

Він установлює прапорець fail, а проблемні символи (a, b, c) залишаються в буфері введення. Після цього кожна наступна спроба std::cin >> int знову натрапляє на ті самі abc і знову завершується невдачею. Виникає ефект «дня бабака»: ви просите число, а потік щоразу впирається в ті самі літери.

Мінімальний приклад:

#include <iostream>

int main() {
    int a = 0;
    int b = 0;

    std::cin >> a;
    std::cin >> b;

    std::cout << "fail=" << std::cin.fail() << '\n';
    std::cout << "a=" << a << " b=" << b << '\n';
}

Якщо користувач уведе 123 abc, то ви побачите приблизно таку картину:

• a прочиталося: 123
• b не прочиталося, бо abc не перетворюється на int
• fail=1
• b залишилося рівним 0 (або попередньому значенню, якщо воно було)

Ключовий висновок: після fail() потік сам не «одужує». Так зроблено навмисно: інакше програма продовжила б працювати так, ніби нічого не сталося, і ви отримували б тихі, дуже неприємні помилки.

На наступній лекції ми навчимося правильно відновлювати потік, але сьогодні нам важливо зафіксувати сам механізм: fail() — це не «один раз не вийшло», а «тепер я в режимі помилки, доки мене не полагодять».

4. eof() і bad(): різні причини зупинки

Чому eof() не можна перевіряти заздалегідь

З EOF (end-of-file, кінець введення) у новачків часто трапляється маленька філософська трагедія: хочеться запитати в потоку «а дані ще є?», а вже потім читати. Але насправді eof() стає істинним після невдалої спроби читання, коли потік уже зрозумів: «далі даних немає».

Тому зазвичай працює такий підхід: «читаємо, доки читається».

#include <iostream>

int main() {
    int x = 0;

    while (std::cin >> x) {
        std::cout << "read: " << x << '\n';
    }

    if (std::cin.eof()) {
        std::cout << "Stopped by EOF\n";
    } else if (std::cin.fail()) {
        std::cout << "Stopped by format error\n";
    } else if (std::cin.bad()) {
        std::cout << "Stopped by bad stream\n";
    }
}

Цей цикл акуратно покриває два різні сценарії:

• користувач або платформа передали набір чисел, а потім введення завершилося → цикл закінчиться, а eof() буде true
• користувач посередині порушив формат введення → цикл закінчиться, а fail() буде true

Це різні причини зупинки, тому їх і потрібно розрізняти.

bad() — рідкісна, але важлива «червона кнопка»

Про bad() можна чесно сказати так: у задачах у Web‑IDE цей стан траплятиметься рідко. Але знати, що він існує, потрібно — хоча б для того, щоб правильно розуміти природу помилок.

Якщо fail() — це «не зміг розібрати формат», то bad() — це «зламався сам потік введення». Наприклад, через проблеми з пристроєм, серйозні помилки буфера тощо. У звичайних навчальних задачах таке майже не трапляється, але в реальних програмах, які читають файли чи дані з мережі, це можливо.

Практичний висновок для новачка такий: якщо бачите bad(), то зазвичай припиняємо роботу, бо «лагодити» там часто вже нічого на вашому рівні. У межах цього заняття будемо вважати bad() «аварією», а fail() — «помилкою користувача».

5. Читання як мініавтомат станів

Коли ви пишете програми з введенням, корисно тримати в голові просту діаграму: спроба читання переводить потік в один із кількох станів, і ваш код має на це відреагувати.

flowchart TD
    A["Спроба читання: std::cin >> x"] --> B{Успіх?}
    B -- "так" --> C["Використовуємо x й рухаємося далі"]
    B -- "ні" --> D{Причина?}
    D -- "EOF" --> E["Завершуємо: даних більше немає"]
    D -- "fail" --> F["Помилка формату: користувач увів не те"]
    D -- "bad" --> G["Серйозна помилка потоку: аварійне завершення"]

Це не «теорія заради теорії». Це ваш захист від хаотичного дебагу: коли програма поводиться дивно, ви не ворожите за фазами Місяця, а ставите собі запитання: «Ми потрапили у fail? У eof?».

6. Практика: читаємо команди й коректно завершуємося

Щоб не лишати тему в повітрі, зробімо маленький крок у бік навчального застосунку.

Уявімо, що раніше, на занятті про struct, ми створили просту модель задачі:

• id — ціле число
• title — коротке слово без пробілів (поки без getline, щоб не змішувати теми)

Сьогодні ми не будемо «лікувати» некоректне введення — це тема наступної лекції, — але навчимося коректно розпізнавати причину зупинки.

#include <iostream>
#include <string>
#include <vector>

struct Task {
    int id = 0;
    std::string title;
};

int main() {
    std::vector<Task> tasks;

    Task t;
    while (std::cin >> t.id >> t.title) {
        tasks.push_back(t);
    }

    std::cout << "Loaded tasks: " << tasks.size() << '\n';

    if (std::cin.eof()) {
        std::cout << "Reason: EOF\n";
    } else if (std::cin.fail()) {
        std::cout << "Reason: format error\n";
    } else if (std::cin.bad()) {
        std::cout << "Reason: bad stream\n";
    }
}

Як це працюватиме:

Якщо введення має такий вигляд:

1 wash
2 code
3 sleep

а потім введення завершується, ви отримаєте Reason: EOF.

Якщо введення має такий вигляд:

1 wash
two code
3 sleep

то цикл зупиниться на рядку two code, і ви отримаєте Reason: format error. Це чесна поведінка: ми не вдаємо, що все добре.

Зверніть увагу на головну ідею: поки ми не вміємо відновлювати потік, найбезпечніший варіант — зупинитися й повідомити причину. Це вже робить програму передбачуваною.

7. Типові помилки під час роботи зі станами std::cin

Помилка № 1: використовувати дані без перевірки std::cin >> x.
Найчастіший сценарій: прочитали int, не перевірили, а потім використовуєте x в обчисленнях. На некоректному введенні ви отримуєте не «помилку», а «тихе сміття» — старе значення змінної. Розвʼязується це простою дисципліною: або if (std::cin >> x), або цикл while (std::cin >> x).

Помилка № 2: перевіряти eof() до читання і будувати на цьому логіку.
eof() зазвичай стає істинним лише після того, як ви спробували прочитати й не змогли через кінець даних. Тому логіка на кшталт «доки не eof, читай» часто дає зайву ітерацію й дивну поведінку. Надійніше читати «доки читається»: while (std::cin >> x).

Помилка № 3: плутати fail() і eof() та писати одне повідомлення «не вийшло».
Кінець введення й помилка формату — це різні ситуації. В одній даних більше немає, і це нормально, в іншій користувач увів не те, і це вже помилка у сценарії введення. Якщо ви їх змішуєте, то не розумієте, що саме зламалося, і не можете задати коректну логіку поведінки програми.

Помилка № 4: намагатися читати далі після fail() і чекати, що все виправиться саме собою.
Після fail() потік не просувається, а помилкові символи зазвичай залишаються в буфері. Наступні операції читання не «перестрибують» через сміття. Через це виникає відчуття, що програма «зависла» або «ігнорує введення». На наступній лекції ми розберемо, як це виправити, відновивши потік, але сьогодні важливо запамʼятати сам факт: fail() — це стійкий стан помилки.

Помилка № 5: ігнорувати bad(), ніби це те саме, що fail().
Навіть якщо в навчальних задачах це рідкість, за змістом bad() — серйозніша ситуація. fail() часто означає «користувач увів не те», а bad() — «зламався сам механізм введення». На рівні базового курсу розумна реакція на bad() — завершити роботу й не намагатися «продовжувати, ніби нічого не сталося».