Odpowiedź.

Praca ze standardowymi strumieniami wejścia/wyjścia jest fundamentem programowania w C.

Historia zagadnienia

Pierwsza implementacja stdio w C (przez <stdio.h>) zakładała istnienie trzech standardowych strumieni: stdin (standardowe wejście), stdout (standardowe wyjście) i stderr (standardowy strumień błędów). Strumienie te pozwalają pisać przenośny kod do interakcji z użytkownikiem i narzędziami automatyzacji.

Problem

Nie wszyscy znają szczegóły: strumienie można przekierowywać, buforowanie jest różne, błędne operowanie na buforach lub kolejności zamykania może prowadzić do niespodziewanych awarii i utraty danych.

Rozwiązanie

Wszystkie standardowe funkcje wejścia/wyjścia domyślnie działają ze stdin, stdout lub stderr. Można je przekierować przez system operacyjny (na przykład poleceniem w shellu), a także w samej programie — przez freopen lub setvbuf w celu zarządzania buforowaniem.

Przykład kodu (przekierowanie stdout do pliku):

#include <stdio.h>

int main() {
    FILE *fp = freopen("output.txt", "w", stdout);
    if (!fp) {
        perror("freopen nie powiodło się");
        return 1;
    }
    printf("To trafi do pliku output.txt!
");
    fclose(fp); // Zamykanie! Może być konieczne jawne zamknięcie stdout
    return 0;
}

Kluczowe cechy:

• stdin, stdout i stderr są zawsze zdefiniowane i automatycznie otwarte
• stdout zazwyczaj jest buforowany w trybie linii, stderr — zawsze niebuforowany (bez bufora), co jest ważne dla wyjścia błędów
• Można przekierowywać strumienie przez shell lub programowo (freopen)

Pytania z podstępem.

Czy można przekazywać deskryptory stdin, stdout lub stderr do innych procesów i robić z nimi, co się chce?

Tylko jeśli system operacyjny wspiera dziedziczenie deskryptorów (na przykład w Unix przez fork), jednak nie zawsze działa to poprawnie, zwłaszcza przy mieszaniu niskopoziomowego wejścia/wyjścia (read/write) i stdio (fgets/printf) — może wystąpić niespójność buforów.

Czy należy ręcznie opróżniać (flush) stdout i stderr?

Dla stdout — opróżnienie (fflush) jest potrzebne, jeśli trzeba mieć pewność, że dane zostały natychmiast zapisane (na przykład przed nagłym zakończeniem programu). stderr zazwyczaj nie wymaga tego, jego wyjście jest natychmiastowe.

Co się stanie, jeśli nie zamkniesz przekierowanego stdout?

Może zostać utracona część danych z powodu nieopróżnionego bufora! Ważne jest, aby jawnie zamykać strumień (fclose) lub wykonywać fflush(stdout) przed zakończeniem programu.

Przykład kodu:

fclose(stdout); // spowoduje opróżnienie bufora i zamknięcie strumienia

Typowe błędy i antywzorce

Zalety: Ujednolicony interfejs, buforowanie dla zwiększenia szybkości, łatwa wymiana wyjścia podczas testowania

Wady: Utrata danych przy zapomnianym fflush/fclose, złożoność przy łączeniu stdio i niskopoziomowego io, utrata widoczności błędów przy zaledwie stdout i stderr

Przykład z życia

Negatywny przypadek: Narzędzie testowe redefiniuje stdout, a następnie zapomina zamknąć strumień — 20% wyników w pliku jest tracone. Zalety: nie trzeba zmieniać pozostałej części kodu, wady: utrata danych i trudna diagnostyka.

Pozytywny przypadek: Program wyprowadza raporty na stdout i błędy na stderr, do debugowania stderr zawsze idzie od razu (bez bufora), po zakończeniu bloku raportowania wykonywane jest fflush(stdout). Zalety: szybka reakcja na błędy, niezawodne zapisanie raportów; wady: wymaga dyscypliny w pracy z buforami.