Aplikacje strumieniowe

Co to jest aplikacja strumieniowa?
A
Najkrócej, łopatologicznie i obrazowo: młynek z dwoma rurami. Jedną rurą znaki wpadają do młynka, drugą wypadają:

  .
  .
  .

  A
  
  C               ,--------.
                  |        |
   X   -----------| MŁYNEK |-----------
      Q  R  T  D  >        >  R  T  A  G
       -----------|        |-----------   B
                  |        |
                  `--------'               U

                                           S
                                           
                                           .
                                           .
                                           .

Mówiąc bardziej formalnie: aplikacja ma na wejściu (rura po lewej na obrazku) ciąg znaków i wyprowadza na wyjście (rura po prawej na obrazku) również ciąg znaków. Aplikacja może pobierać kolejno znaki z wejścia i kolejno wyprowadzać je na wyjście. W międzyczasie może je sobie mielić. Na tym, dokładnie na tym, kończy się działanie tej aplikacji. Nie ma praktycznie żadnego wpływu ani na źródło danych, ani na odbiorcę danych. Do rur mogą być podłączane najróżniejsze rzeczy i aplikacji nie interesuje, co tam będzie. Przykładowo może to być plik, inny program, połączenie TCP/IP, port komputera z podłączonym pod niego czujnikiem, mikrofon/głośnik, sterownik jakiegoś urządzenia, drukarka lub nawet "nic". To tylko proste przykłady, nie pełna lista! Co by jednak nie było, jest to zwykle poza zainteresowaniami aplikacji. Aplikacja normalnie nie ma też większego wpływu na to, skąd się dane biorą i jak są wysyłane. Akceptuje po prostu to, co dostaje. Gdy uruchamiasz w shellu polecenia takie jak ls, netstat czy cat, programów tych nie interesuje, co się dzieje z danymi, które wyprowadza na wyjście. Może trafiają do pliku? Może zostały wywołane ze skryptu, który przechwytuje ich wynik? Może wynik trafia do grepa lub seda, które przetwarzają i filtrują dane? Może, co jest dosyć prawdopodobne do sterownika konsoli, dzięki czemu użytkownik może je zobaczyć. Nie wiadomo. I to są właśnie aplikacje strumieniowe: dwie rury do młynka. Proste, ale w odpowiednich rękach potężne narzędzie.

Praktycznie wszyscy programiści C++ zaczynali przygodę z tym językiem właśnie od aplikacji strumieniowych. Niestety nikt im wcześniej o tym nie powiedział, a domyślne działanie wielu systemów polegające na podłączeniu strumieni pod sterownik konsoli nie ułatwia wcale zauważenia tego prostego faktu. Na dodatek niejeden ich nauczyciel nagadał bzdur, które tylko zaciemniły obraz wszystkiego. Potem pojawiają się pytania takie, jak trzy posty wyżej - o konsolę. Pomimo, że aplikacja nie jest aplikacją konsolową, lecz strumieniową.
Jeżeli padnie pytanie, jak to się zatem dzieje, że wpisywany w konsoli tekst trafia do programu i tekst wyprowadzany jest na ekranie, to wcale się nie zdziwię. Sprzeczności jednak nie ma. Po prostu rury zostały podłączone pod sterownik konsoli. Kolejny wielki młynek. Odbiera od systemu wiadomości o wciśnięciu klawiszy, przetwarza je na znaki, które to znaki sobie zbiera i co jakiś czas wysyła do rury wejściowej podłączonej pod niego aplikacji. Co ile? Różnie, ale najbardziej typowe rozwiązanie to po każdym napotkaniu znaku nowej linii, co jest często równoznaczne naciśnięciu entera. Czyli jeśli naciśniesz kolejno klawisze: A, L, A, <spacja>, M, A, <spacja>, K, O, T, A, <enter>, 1, 2, 4, 8, 1, 2, <enter>, Q, W, E... taki sterownik konsoli wykona następujące rzeczy:
Klawisz Bufor sterownika Rura wejściowa
---------------------------------------------------------------

            ""                      ""
A           "A"                     ""
L           "AL"                    ""
A           "ALA"                   ""
<spacja>    "ALA "                  ""
M           "ALA M"                 ""
A           "ALA MA"                ""
<spacja>    "ALA MA "               ""
K           "ALA MA K"              ""
O           "ALA MA KO"             ""
T           "ALA MA KOT"            ""
A           "ALA MA KOTA"           ""
<enter>     -- wysłanie ------>     "ALA MA KOTA\n"
1           "1"                     "ALA MA KOTA\n"
2           "12"                    "ALA MA KOTA\n"
4           "124"                   "ALA MA KOTA\n"
8           "1248"                  "ALA MA KOTA\n"
1           "12481"                 "ALA MA KOTA\n"
2           "124812"                "ALA MA KOTA\n"
<enter>     -- wysłanie ------->    "ALA MA KOTA\n124812\n"
Q           "Q"                     "ALA MA KOTA\n124812\n"
W           "QW"                    "ALA MA KOTA\n124812\n"
E           "QWE"                   "ALA MA KOTA\n124812\n"

Jeżeli przed pierwszym naciśnięciem entera program będzie próbował czytać z wejścia, to implementacja zobaczy, że rura jest pusta i będzie czekała, aż coś się w rurze pojawi. Gdy wreszcie po naciśnięciu entera coś się pojawi, będzie to czytała. Potem znowu się zablokuje, gdy rura się opróżni i znowu będzie czekała, aż będzie coś nadającego się do "zjedzenia". Z tego wynika "czekanie" aplikacji na wpisanie czegoś od użytkownika. To nie operator >> powoduje, że aplikacja zatrzymuje się, a ty możesz coś wpisać i potwierdzić to enterem. Aplikcja blokuje się, bo czeka na dane. Dane te otrzymuje od sterownika konsoli, który sam je sobie zbiera. Aplikacja nie ma większego wpływu ani na to, skąd te dane tak naprawdę będą, ani na to, jak będą wpisywane. Teraz rozumiesz, czemu pytanie o to, jak uniemożliwić wpisanie jakiegoś znaku jest bez sensu? Dlatego, że to nie twoja aplikacja robi to czarne okienko, nie ona odczytuje wciśnięte klawisze, nie ona wyświetla odpowiadające im znaki przy kursorze i nie on przesuwa kursor - to wszystko robi zupełnie inny program, który dopiero w pewnym momencie już skompletowane dane wysyła do twojej aplikacji. Przenosząc się do strony, że się tak wyrażę, tylnej - dlaczego dane wyświetlają się na ekranie? Bo sterownik konsoli odczytuje dane z rury wylotowej. Sprawdza co to za dane, interpretuje je w razie konieczności i wyświetla. Po raz kolejny: to nie twoja aplikacja cokolwiek wyświetla. Ona nawet nie wydaje polecenia wyświetlenia. Jedyne co robi, to w rurę wyjściową pakuje dane, które trafiają dopiero do urządzenia, które po ich analizie przeprowadza operację ich wyświetlenia. Ponieważ nie twoja aplikacja cokolwiek rysuje i nie ona wyświetla to okienko, to również pytanie o to, jak zmienić twoją aplikację, by sterowała tym okienkiem, są nieporozumieniem. Twoja aplikacja nie może tego zrobić bezpośrednio, bo to nie ona tym wszystkim zarządza.
W najlepszym przypadku może wykorzystać fakt, że sterowniki konsoli mogą używać protokołu zawierającego jakieś polecenia. Np. terminale ANSI miały zbiór poleceń pozwalający powiedzieć im (bo to nadal one wszystko kontrolowały), że mają zmienić kolor czcionki, przenieść kursor czy wyczyścić ekran. Stosowanie takich technik ma jednak dwie istotne wady. Po pierwsze są nieprzenośne. Po drugie w dzisiejszych czasach istnieją gotowe biblioteki do sterowania konsolą, w których można wszystko zrobić kilkoma prostymi funkcjami zamiast zapychania kodu programu masą brzydkich krzaczków.

Posługując się jeszcze jedną analogią: twój program jest krową na pastwisku. Pytanie o zmianę sposobu wprowadzania danych do programu jest równie sensowne, co pytanie, jak przerobić krowę, żeby trawa szybciej rosła. Pytanie o zmianę sposobu wyświetlania danych z programu jest równie sensowne, co pytanie, jak przerobić krowę, żeby pan Józio przyjeżdżał po jej odchody w poniedziałki, a nie środy. Oczywiście mućki nie zmienisz. Krowa zawsze będzie jedną stroną pobierała zielone dane wejściowe, a drugą stroną wyrzucała plackowate dane wyjściowe, bo taki jest jej żywot (jak zresztą każdego większego żywego stworzenia).

Miłego tworzenia owych aplikacji. Pozdro Liczę na +