Kto zaprojektował / zaprojektował IOStreams w C ++ i czy nadal będzie uważany za dobrze zaprojektowany według dzisiejszych standardów? [Zamknięte]

Po pierwsze, może się wydawać, że proszę o subiektywne opinie, ale nie o to mi chodzi. Bardzo chciałbym usłyszeć kilka uzasadnionych argumentów na ten temat.

Mając nadzieję na trochę wglądu w to, jak powinny być projektowane nowoczesne ramy strumieni / serializacji, niedawno kupiłem książkę Standard C ++ IOStreams and Locales autorstwa Angeliki Langer i Klausa Krefta . Pomyślałem, że gdyby IOStreams nie był dobrze zaprojektowany, to w pierwszej kolejności nie trafiłby do standardowej biblioteki C ++.

Po przeczytaniu różnych części tej książki zaczynam wątpić, czy IOStreams można porównać np. Z STL z ogólnego architektonicznego punktu widzenia. Przeczytaj na przykład ten wywiad z Alexandrem Stepanovem („wynalazcą” STL), aby dowiedzieć się o niektórych decyzjach projektowych, które zostały podjęte w ramach STL.

Co mnie szczególnie zaskakuje :

• Wydaje się, że nie wiadomo, kto był odpowiedzialny za ogólny projekt IOStreams (chciałbym przeczytać kilka podstawowych informacji na ten temat - czy ktoś zna dobre zasoby?);

• Gdy zagłębisz się w bezpośrednią powierzchnię IOStreams, np. Jeśli chcesz rozszerzyć IOStreams o własne klasy, otrzymasz interfejs z dość tajemniczymi i mylącymi nazwami funkcji składowych, np. getloc/ imbue, uflow/ underflow, snextc/ sbumpc/ sgetc/ sgetn, pbase/ pptr/ epptr(I jest prawdopodobnie jeszcze gorsze przykłady). To sprawia, że ​​znacznie trudniej jest zrozumieć ogólny projekt i sposób, w jaki poszczególne części współpracują. Nawet książka, o której wspomniałem powyżej, nie pomaga tak bardzo (IMHO).

Stąd moje pytanie:

Gdybyś musiał oceniać na podstawie dzisiejszych standardów inżynierii oprogramowania (jeśli faktycznie istnieje jakakolwiek ogólna zgoda co do nich), czy IOStreams w C ++ nadal byłoby uważane za dobrze zaprojektowane? (Nie chciałbym podnosić swoich umiejętności projektowania oprogramowania z czegoś, co jest ogólnie uważane za przestarzałe).

Kilka nieprzemyślane pomysły trafiły do normy: auto_ptr, vector<bool>, valarrayi export, żeby wymienić tylko kilka. Dlatego nie uważałbym obecności IOStreams za oznakę dobrego projektu.

IOStreams ma burzliwą historię. W rzeczywistości są one przeróbką wcześniejszej biblioteki strumieni, ale zostały stworzone w czasie, gdy wiele dzisiejszych idiomów C ++ nie istniało, więc projektanci nie mieli korzyści z perspektywy czasu. Jedną z kwestii, która stała się oczywista z czasem, było to, że prawie niemożliwe jest wdrożenie IOStreams tak wydajnie, jak stdio C, ze względu na obfite wykorzystanie funkcji wirtualnych i przekazywanie do wewnętrznych obiektów buforowych przy nawet najmniejszej ziarnistości, a także dzięki pewnej niezrozumiałej dziwności. w sposobie definiowania i implementacji ustawień regionalnych. Muszę przyznać, że pamięć o tym jest dość niewyraźna; Pamiętam, że był to temat intensywnej debaty kilka lat temu, moderowana na comp.lang.c ++.

Jeśli chodzi o to, kto je zaprojektował, oryginalna biblioteka została (nie jest zaskoczeniem) stworzona przez Bjarne Stroustrupa, a następnie ponownie zaimplementowana przez Dave Presotto. Zostało to następnie przeprojektowane i ponownie zaimplementowane przez Jerry'ego Schwarza dla Cfront 2.0, wykorzystując ideę manipulatorów Andrew Koeniga. Standardowa wersja biblioteki jest oparta na tej implementacji.

Źródło „Projekt i ewolucja języka C ++”, sekcja 8.3.1.

Gdybyś musiał oceniać na podstawie dzisiejszych standardów inżynierii oprogramowania (jeśli faktycznie istnieje jakakolwiek ogólna zgoda co do nich), czy IOStreams w C ++ nadal byłoby uważane za dobrze zaprojektowane? (Nie chciałbym podnosić swoich umiejętności projektowania oprogramowania z czegoś, co jest powszechnie uważane za przestarzałe).

Powiedziałbym NIE z kilku powodów:

Słaba obsługa błędów

Warunki błędów należy zgłaszać z wyjątkami, a nie z operator void*.

Anty-wzorzec „obiektu zombie” powoduje takie błędy .

Słaba separacja między formatowaniem a we / wy

To sprawia, że ​​obiekty strumieniowe są niepotrzebnie złożone, ponieważ muszą zawierać dodatkowe informacje o stanie do formatowania, niezależnie od tego, czy jest to potrzebne, czy nie.

Zwiększa również prawdopodobieństwo pisania błędów, takich jak:

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

Jeśli zamiast tego napisałeś coś takiego:

cout << pad(to_hex(x), 8, '0') << endl;

Nie byłoby bitów stanu związanych z formatowaniem i nie byłoby problemu.

Zauważ, że we "nowoczesnych" językach, takich jak Java, C # i Python, wszystkie obiekty mają funkcję toString/ ToString/, __str__która jest wywoływana przez procedury we / wy. AFAIK, tylko C ++ robi to na odwrót, używając stringstreamjako standardowego sposobu konwersji na ciąg.

Słabe wsparcie dla i18n

Dane wyjściowe oparte na Iostream dzielą literały ciągów na części.

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

Ciągi formatujące umieszczają całe zdania w literałach łańcuchowych.

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

To drugie podejście jest łatwiejsze do dostosowania do bibliotek internacjonalizacji, takich jak GNU gettext, ponieważ użycie całych zdań zapewnia tłumaczom szerszy kontekst. Jeśli twoja procedura formatowania łańcuchów obsługuje zmianę kolejności (jak $parametry POSIX printf), to również lepiej radzi sobie z różnicami w kolejności słów między językami.

Publikuję to jako osobną odpowiedź, ponieważ jest to czysta opinia.

Wykonywanie operacji wejścia i wyjścia (szczególnie wejścia) jest bardzo, bardzo trudnym problemem, więc nie jest zaskakujące, że biblioteka iostreams jest pełna elementów i rzeczy, które z perspektywy czasu można było zrobić lepiej. Ale wydaje mi się, że wszystkie biblioteki I / O, w jakimkolwiek języku są takie. Nigdy nie używałem języka programowania, w którym system I / O byłby piękną rzeczą, która sprawiała, że ​​podziwiałem jego projektanta. Biblioteka iostreams ma zalety, szczególnie w porównaniu z biblioteką CI / O (rozszerzalność, bezpieczeństwo typów itp.), Ale nie sądzę, aby ktokolwiek traktował ją jako przykład świetnego OO lub ogólnego projektu.

Moja opinia o C ++ iostreams znacznie się poprawiła w czasie, szczególnie po tym, jak zacząłem je rozszerzać, implementując własne klasy strumieniowe. Zacząłem doceniać rozszerzalność i ogólny projekt, pomimo śmiesznie kiepskich nazw funkcji składowych, takich jak xsputnczy cokolwiek innego. Niezależnie od tego, myślę, że strumienie I / O są ogromnym ulepszeniem w stosunku do C stdio.h, które nie ma bezpieczeństwa typów i jest pełne poważnych luk w zabezpieczeniach.

Myślę, że głównym problemem ze strumieniami we / wy jest to, że łączą one dwie powiązane, ale nieco ortogonalne koncepcje: formatowanie tekstu i serializację. Z jednej strony strumienie we / wy są przeznaczone do tworzenia czytelnej dla człowieka, sformatowanej tekstowej reprezentacji obiektu, az drugiej do serializacji obiektu do formatu przenośnego. Czasami te dwa cele są takie same, ale innym razem prowadzi to do poważnych irytujących niekongruencji. Na przykład:

std::stringstream ss;
std::string output_string = "Hello world";
ss << output_string;

...

std::string input_string;
ss >> input_string;
std::cout << input_string;

Tutaj to, co otrzymujemy jako dane wejściowe, nie jest tym, co pierwotnie wyprowadziliśmy do strumienia. Dzieje się tak, ponieważ <<operator wyprowadza cały ciąg, podczas gdy >>operator będzie czytać ze strumienia tylko do momentu napotkania znaku odstępu, ponieważ w strumieniu nie ma informacji o długości . Więc nawet jeśli wypisujemy obiekt typu string zawierający "hello world", wprowadzimy tylko obiekt typu string zawierający "hello". Więc chociaż strumień spełnił swoje zadanie jako narzędzie do formatowania, nie udało mu się poprawnie serializować, a następnie odserializować obiektu.

Można powiedzieć, że strumienie we / wy nie zostały zaprojektowane jako urządzenia do serializacji, ale jeśli tak jest, do czego naprawdę służą strumienie wejściowe ? Poza tym w praktyce strumienie I / O są często używane do serializacji obiektów, ponieważ nie ma innych standardowych narzędzi do serializacji. Rozważmy boost::date_timelub boost::numeric::ublas::matrix, gdzie jeśli wyjście obiekt matryca z <<operatorem, dostaniesz dokładnie taki sam matrycę gdy wejście jest za pomocą >>operatora. Ale aby to osiągnąć, projektanci Boost musieli przechowywać informacje o liczbie kolumn i liczbie wierszy jako dane tekstowe na wyjściu, co zagraża rzeczywistemu czytelnemu dla człowieka wyświetlaczowi. Znowu niezręczne połączenie funkcji formatowania tekstu i serializacji.

Zwróć uwagę, jak większość innych języków oddziela te dwie usługi. Na przykład w Javie formatowanie odbywa się za pomocą toString()metody, a serializacja za pośrednictwem Serializableinterfejsu.

Moim zdaniem najlepszym rozwiązaniem byłoby wprowadzenie strumieni opartych na bajtach , obok standardowych strumieni opartych na znakach . Te strumienie działałyby na danych binarnych, bez obawy o formatowanie / wyświetlanie czytelne dla człowieka. Mogą być używane wyłącznie jako narzędzia serializacji / deserializacji, do tłumaczenia obiektów C ++ na przenośne sekwencje bajtów.

Zawsze uważałem, że C ++ IOStreams jest źle zaprojektowany: ich implementacja bardzo utrudnia prawidłowe zdefiniowanie nowego typu strumienia. łączą również funkcje io i funkcje formatowania (pomyśl o manipulatorach).

Osobiście najlepszy projekt i implementacja strumienia, jaki kiedykolwiek znalazłem, leży w języku programowania Ada. jest wzorem odsprzęgania, radością z tworzenia nowych typów strumieni, a funkcje wyjściowe działają zawsze niezależnie od używanego strumienia. Dzieje się tak dzięki najmniejszemu wspólnemu mianownikowi: wysyłasz bajty do strumienia i to wszystko. funkcje strumieniowe dbają o umieszczenie bajtów w strumieniu, ich zadaniem nie jest np. formatowanie liczby całkowitej na szesnastkową (oczywiście istnieje zestaw atrybutów typu, odpowiednik składowej klasy, zdefiniowany do obsługi formatowania)

Chciałbym, żeby C ++ był tak prosty w odniesieniu do strumieni ...

Myślę, że projekt IOStreams jest genialny pod względem możliwości rozbudowy i użyteczności.

1. Bufory strumieniowe: spójrz na rozszerzenia boost.iostream: twórz gzip, tee, kopiuj strumienie w kilku wierszach, twórz specjalne filtry i tak dalej. Bez niej nie byłoby to możliwe.

2. Integracja lokalizacji i integracja formatowania. Zobacz, co można zrobić:

   std::cout << as::spellout << 100 << std::endl;
   

   Można wydrukować: „sto” lub nawet:

   std::cout << translate("Good morning")  << std::endl;
   

   Można wydrukować „Bonjour” lub „בוקר טוב” w zależności od ustawień regionalnych std::cout!

   Takie rzeczy można zrobić tylko dlatego, że iostreamy są bardzo elastyczne.

Czy można to zrobić lepiej?

Oczywiście, że tak! W rzeczywistości jest wiele rzeczy, które można by poprawić ...

Dziś jest to dość bolesne, aby wyprowadzić z stream_bufferniego poprawnie , dodanie dodatkowych informacji o formatowaniu do strumienia jest dość nietrywialne, ale możliwe.

Ale patrząc wstecz wiele lat temu, nadal projekt biblioteki był na tyle dobry, że mógł przynieść wiele gadżetów.

Ponieważ nie zawsze możesz zobaczyć pełny obraz, ale jeśli zostawisz punkty za rozszerzenia, daje to znacznie lepsze możliwości, nawet w punktach, o których nie myślałeś.

(Ta odpowiedź jest oparta na mojej opinii)

Myślę, że IOStreamy są znacznie bardziej złożone niż ich odpowiedniki funkcyjne. Kiedy piszę w C ++, nadal używam nagłówków cstdio dla "starego stylu" I / O, które uważam za dużo bardziej przewidywalne. Na marginesie (chociaż nie jest to naprawdę ważne; bezwzględna różnica czasu jest znikoma) wielokrotnie udowodniono, że IOStreams są wolniejsze niż CI / O.

Korzystając z IOStream zawsze napotykam niespodzianki.

Biblioteka wydaje się być zorientowana na tekst, a nie binarnie. To może być pierwsza niespodzianka: użycie flagi binarnej w strumieniach plików nie wystarczy do uzyskania zachowania binarnego. Użytkownik Charles Salvia powyżej zaobserwował to poprawnie: IOStreams miesza aspekty formatowania (gdzie chcesz uzyskać ładny wynik, np. Ograniczone cyfry dla liczb zmiennoprzecinkowych) z aspektami serializacji (gdzie nie chcesz utraty informacji). Prawdopodobnie dobrze byłoby oddzielić te aspekty. Boost.Serialization robi to za połowę. Masz funkcję serializacji, która kieruje do elementów wstawiających i wyodrębniających, jeśli chcesz. Już masz napięcie między oboma aspektami.

Wiele funkcji ma również mylącą semantykę (np. Get, getline, ignore and read. Niektóre wyodrębniają ogranicznik, inne nie; także niektóre set eof). Dalej niektórzy wspominają o dziwnych nazwach funkcji podczas implementowania strumienia (np. Xsputn, uflow, underflow). Sytuacja się pogarsza, gdy używa się wariantów wchar_t. Wifstream wykonuje tłumaczenie na wielobajtowe, podczas gdy wstringstream nie. Binarne I / O nie działa po wyjęciu z pudełka z wchar_t: masz nadpisać codecvt.

Buforowane we / wy c (tj. PLIK) nie jest tak potężne jak jego odpowiednik w C ++, ale jest bardziej przejrzyste i ma znacznie mniej intuicyjne zachowanie.

Jednak za każdym razem, gdy napotykam IOStream, przyciąga mnie jak ćma do ognia. Prawdopodobnie byłoby dobrze, gdyby jakiś naprawdę sprytny facet dobrze przyjrzał się całej architekturze.

Nie mogę nie odpowiedzieć na pierwszą część pytania (kto to zrobił?). Ale odpowiedziano na to w innych postach.

Jeśli chodzi o drugą część pytania (dobrze zaprojektowana?), Moja odpowiedź brzmi: „Nie!”. Oto mały przykład, który od lat sprawia, że ​​kręcę głową z niedowierzaniem:

#include <stdint.h>
#include <iostream>
#include <vector>

// A small attempt in generic programming ;)
template <class _T>
void ShowVector( const char *title, const std::vector<_T> &v)
{
    std::vector<_T>::const_iterator iter;
    std::cout << title << " (" << v.size() << " elements): ";
    for( iter = v.begin(); iter != v.end(); ++iter )
    {
        std::cout << (*iter) << " ";
    }
    std::cout << std::endl;
}
int main( int argc, const char * argv[] )
{
    std::vector<uint8_t> byteVector;
    std::vector<uint16_t> wordVector;
    byteVector.push_back( 42 );
    wordVector.push_back( 42 );
    ShowVector( "Garbled bytes as characters output o.O", byteVector );
    ShowVector( "With words, the numbers show as numbers.", wordVector );
    return 0;
}

Powyższy kod generuje bzdury z powodu projektu iostream. Z pewnych powodów, których nie rozumiem, traktują bajty uint8_t jako znaki, podczas gdy większe typy całkowite są traktowane jak liczby. Qed Zły projekt.

Nie mogę też wymyślić sposobu, aby to naprawić. Typ może równie dobrze być zmiennoprzecinkowy lub podwójny ... więc rzutowanie na 'int', aby głupi iostream zrozumiał, że tematem są liczby, a nie znaki, nie pomoże.

Po otrzymaniu negatywnej opinii na moją odpowiedź, może jeszcze kilka słów wyjaśnienia ... Projekt IOStream jest wadliwy, ponieważ nie daje programiście możliwości określenia JAK przedmiot jest traktowany. Implementacja IOStream podejmuje arbitralne decyzje (takie jak traktowanie uint8_t jako znaku, a nie liczby bajtów). To jest wada projektu IOStream, ponieważ próbują osiągnąć nieosiągalne.

C ++ nie pozwala na klasyfikację typu - język nie ma takiej możliwości. Nie ma czegoś takiego jak is_number_type () lub is_character_type (), którego IOStream mógłby użyć do dokonania rozsądnego automatycznego wyboru. Ignorowanie tego i próba uniknięcia zgadywania JEST wadą konstrukcyjną biblioteki.

Przyjęto, że printf () równie nie zadziałaby w ogólnej implementacji „ShowVector ()”. Ale to nie usprawiedliwia zachowania iostream. Ale jest bardzo prawdopodobne, że w przypadku printf () ShowVector () zostałby zdefiniowany w ten sposób:

template <class _T>
void ShowVector( const char *formatString, const char *title, const std::vector<_T> &v );

C ++ iostreamy mają wiele wad, jak zauważono w innych odpowiedziach, ale chciałbym zwrócić uwagę na coś na jego obronę.

C ++ jest praktycznie wyjątkowy wśród poważnie używanych języków, dzięki czemu zmienne dane wejściowe i wyjściowe są proste dla początkujących. W innych językach dane wejściowe użytkownika zwykle obejmują wymuszanie typu lub elementy formatujące ciąg, podczas gdy C ++ sprawia, że ​​kompilator wykonuje całą pracę. To samo dotyczy głównie danych wyjściowych, chociaż C ++ nie jest tak wyjątkowy pod tym względem. Mimo to możesz całkiem dobrze wykonywać sformatowane operacje we / wy w C ++ bez konieczności rozumienia klas i pojęć zorientowanych obiektowo, co jest przydatne pedagogicznie i bez konieczności rozumienia składni formatu. Ponownie, jeśli uczysz początkujących, to duży plus.

Ta prostota dla początkujących ma swoją cenę, która może przyprawić o ból głowy w przypadku radzenia sobie z I / O w bardziej złożonych sytuacjach, ale miejmy nadzieję, że w tym momencie programista nauczył się wystarczająco dużo, aby móc sobie z nimi poradzić, lub przynajmniej stał się wystarczająco stary pić.