Хто архітектурно розробляв C ++ IOStreams, і чи вважатиметься він добре розробленим за сьогоднішніми стандартами? [зачинено]

По-перше, може здатися, що я прошу суб'єктивних думок, але це не те, що я після цього. Я хотів би почути кілька обґрунтованих аргументів на цю тему.

Сподіваючись отримати деяке розуміння того, як має бути спроектована сучасна структура потоків / серіалізації, я нещодавно отримав собі примірник книги Standard C ++ IOStreams and Locales від Angelika Langer та Klaus Kreft . Я подумав, що якби IOStreams не був належним чином розроблений, це не перетворило б його в стандартну бібліотеку C ++.

Прочитавши різні частини цієї книги, у мене виникають сумніви, чи можна IOStreams порівняти, наприклад, STL з загальної архітектурної точки зору. Прочитайте, наприклад, це інтерв'ю з Олександром Степановим ("винахідником" STL), щоб дізнатись про деякі дизайнерські рішення, які увійшли до STL.

Що мене особливо дивує :

• Здається, невідомо, хто відповідав за загальний дизайн IOStreams (я хотів би прочитати довідкову інформацію про це - хтось знає хороші ресурси?);

• Після того, як ви заглибитесь під безпосередню поверхню IOStreams, наприклад, якщо ви хочете розширити IOStreams своїми власними класами, ви потрапляєте на інтерфейс із досить криптовими і заплутаними іменами функцій членів, наприклад, getloc/ imbue, uflow/ underflow, snextc/ sbumpc/ sgetc/ sgetn, pbase/ pptr/ epptr(і є мабуть, ще гірші приклади). Це ускладнює розуміння загальної конструкції та взаємодії окремих деталей. Навіть книга , яку я згадував вище , не допомагає , що багато (ІМХО).

Отже, моє запитання:

Якби вам довелося судити за сьогоднішніми стандартами програмної інженерії (якщо насправді існує якась загальна згода на це), чи все-таки IOStream C ++ все ще вважався б добре розробленим? (Я не хотів би вдосконалювати свої навички проектування програмного забезпечення на основі того, що зазвичай вважається застарілим.)

Кілька непродумані ідеї знайшли свій шлях у стандарт: auto_ptr, vector<bool>, valarrayі export, просто назвати декілька. Тому я б не сприймав наявність IOStreams обов'язково як знак якісного дизайну.

IOStreams має картату історію. Вони насправді є переробкою більш ранньої бібліотеки потоків, але були автором у той час, коли багато сучасних ідіом C ++ не існувало, тому дизайнери не мали переваги заднього огляду. Одне питання, яке стало очевидним лише з часом, - майже неможливо реалізувати IOStreams так ефективно, як stdio C, завдяки рясному використанню віртуальних функцій та переадресації до внутрішніх буферних об’єктів навіть при найтоншій деталізації, а також завдяки деякій непереборній дивацтві у способі визначення та реалізації локальних локалів. Моя пам'ять про це досить нечітка, визнаю; Я пам’ятаю, що вона була предметом бурхливих дебатів кілька років тому на моделях comp.lang.c ++.

Що стосується того, хто їх розробив, оригінальну бібліотеку створив (не дивно) Б'ярн Струструп, а потім повторно доповнив Дейв Пресотто. Потім він був перероблений і знову доповнений Джеррі Шварцом для Cfront 2.0, використовуючи ідею маніпуляторів від Ендрю Кеніга. На цій реалізації базується стандартна версія бібліотеки.

Джерело "Дизайн та еволюція C ++", розділ 8.3.1.

Якби вам довелося судити за сьогоднішніми стандартами інженерії програмного забезпечення (якщо насправді існує якась загальна згода на це), чи вважали б IOStream C ++ таки добре продуманими? (Я не хотів би вдосконалювати свої навички проектування програмного забезпечення на основі того, що зазвичай вважається застарілим.)

Я б сказав « НІ» з кількох причин:

Погане поводження з помилками

Про умови помилок слід повідомляти з винятками, а не з operator void*.

Антидіаграма "об’єкт зомбі" - це те, що викликає подібні помилки .

Погане розмежування між форматуванням і введенням / виведенням

Це робить об'єкти потоку непотрібними складними, оскільки вони повинні містити додаткову інформацію про стан для форматування, потрібна вона вам чи ні.

Це також збільшує шанси написання помилок на кшталт:

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

Якщо замість цього, ви написали щось на кшталт:

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

Не буде жодних бітів, що стосуються форматування, і жодних проблем.

Зауважте, що в "сучасних" мовах, таких як Java, C # і Python, всі об'єкти мають функцію toString/ ToString/, __str__яку викликають підпрограми вводу / виводу. AFAIK, тільки C ++ робить це навпаки, використовуючи stringstreamяк стандартний спосіб перетворення в рядок.

Погана підтримка i18n

Вихід на основі Iostream розбиває буквені рядки на частини.

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

Рядки формату ставлять цілі речення в рядкові букви.

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

Останній підхід легше адаптується до бібліотек інтернаціоналізації, таких як GNU gettext, оскільки використання цілих речень забезпечує більше контексту для перекладачів. Якщо ваша форма форматування рядків підтримує переупорядкування (як параметри POSIX $printf), то воно також краще обробляє відмінності в порядку слів між мовами.

Я публікую це як окрему відповідь, оскільки це чиста думка.

Виконання вводу та виводу (особливо вхідних даних) - дуже, дуже важка проблема, тому не дивно, що бібліотека iostreams повна курганів і речей, які з ідеальним оглядом могли бути зроблені краще. Але мені здається, що всі бібліотеки вводу-виводу будь-якою мовою такі. Я ніколи не використовував мову програмування, де система вводу / виводу була предметом краси, що змусило мене в захваті від свого дизайнера. Бібліотека iostreams має переваги, особливо над бібліотекою CI / O (розширюваність, безпека типу тощо), але я не думаю, що хтось вважає це прикладом чудового OO або загального дизайну.

Моя думка щодо іонів C ++ значно покращилася з часом, особливо після того, як я почав фактично їх розширювати, застосовуючи власні класи потоків. Я почав цінувати розширюваність та загальний дизайн, незважаючи на смішно погані назви функцій членів, як xsputnби то не було. Незважаючи на те, я думаю, що потоки вводу / виводу є значним покращенням порівняно з C stdio.h, який не має безпеки типу і пронизаний великими недоліками безпеки.

Я думаю, що головна проблема потоків IO полягає в тому, що вони поєднують два споріднених, але дещо ортогональних поняття: текстове форматування та серіалізація. З одного боку, потоки вводу-виводу призначені для створення читаного у форматі тексту, зображеного людиною, і, з іншого боку, для серіалізації об'єкта у портативному форматі. Іноді ці дві цілі є одними і тими ж, але в інших випадках це призводить до серйозних роздратованих недоліків. Наприклад:

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

...

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

Тут те, що ми отримуємо як вхід, - це не те, що ми спочатку виводили на потік. Це пояснюється тим, що <<оператор виводить весь рядок, тоді як >>оператор буде читати з потоку лише доти, доки він не зустріне символ пробілу, оскільки в потоці немає інформації про довжину . Тож навіть якщо ми виводимо об’єкт рядка, що містить "привіт світ", ми збираємось лише вводити об'єкт рядка, що містить "привіт". Тому, хоча потік слугував своїм призначенням як інструмент форматування, він не зміг належним чином серіалізувати та потім несеріалізувати об’єкт.

Ви можете сказати, що потоки введення-виведення не були розроблені як засоби серіалізації, але якщо це так, для чого насправді вхідні потоки? Крім того, на практиці потоки вводу / виводу часто використовуються для серіалізації об'єктів, оскільки немає інших стандартних засобів серіалізації. Подумайте, boost::date_timeабо boost::numeric::ublas::matrix, якщо ви виведете об'єкт матриці з <<оператором, ви отримаєте таку ж точну матрицю, коли введете її за допомогою >>оператора. Але для того, щоб досягти цього, дизайнерам Boost довелося зберігати інформацію про кількість стовпців та кількість рядків у вигляді текстових даних у висновку, що компрометує фактичний для людини доступний для читання дисплей. Знову незручне поєднання засобів текстового форматування та серіалізації.

Зверніть увагу, як більшість інших мов розділяє ці два засоби. Наприклад, у Java форматування здійснюється за допомогою toString()методу, тоді як серіалізація здійснюється через Serializableінтерфейс.

На мою думку, найкращим рішенням було б запровадити потоки на байті , поряд із стандартними потоками на основі символів . Ці потоки працюватимуть на двійкових даних, не турбуючись про читане для людини форматування / відображення. Вони можуть використовуватися виключно як засоби серіалізації / десеріалізації для перекладу об'єктів C ++ у переносні послідовності байтів.

Я завжди знаходив C ++ IOStreams погано розробленими: їх реалізація ускладнює правильне визначення потоку нового типу. вони також змішують функції io та функції форматування (подумайте про маніпулятори).

особисто, найкраща розробка та реалізація потоку, яку я коли-небудь знаходив, лежить у мові програмування Ada. це модель для роз'єднання, радість створювати потоки нового типу, а функції виводу завжди працюють незалежно від використовуваного потоку. це подяка щонайменше загального знаменника: ви виводите байти в потік, і все. функції потоку піклуються про введення байтів у потік, це не їхня робота, наприклад, форматування цілого числа в шістнадцятковий (звичайно, є набір атрибутів типу, еквівалентний члену класу, визначений для обробки форматування)

Я хотів би, щоб C ++ був таким же простим щодо потоків ...

Я думаю, що дизайн IOStreams є блискучим з точки зору розширюваності та корисності.

1. Потокові буфери: подивіться на розширення boost.iostream: створюйте gzip, tee, копіюйте потоки в декілька рядків, створюйте спеціальні фільтри тощо. Без цього було б неможливо.

2. Інтеграція локалізації та інтеграція форматування. Подивіться, що можна зробити:

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

   Можна надрукувати: "сто" або навіть:

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

   Можна надрукувати "Bonjour" або "בוקר טוב" відповідно до місцевості, на яку ви прописані std::cout!

   Такі речі можна зробити лише тому, що іострим є дуже гнучким.

Чи можна це зробити краще?

Звичайно, це могло! Насправді є багато речей, які можна було б покращити ...

Сьогодні це досить болісно правильно виводити stream_buffer, додавати додаткову інформацію про форматування в потік досить нетривіально, але можливо.

Але озираючись назад багато років тому, я все-таки дизайн бібліотеки був досить хорошим, щоб збиратися принести багато смаколиків.

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

(Ця відповідь якраз і грунтується на моїй думці)

Я думаю, що IOStreams набагато складніші за їх еквіваленти функцій. Коли я пишу на C ++, я все-таки використовую заголовки cstdio для вводу-виводу "старого стилю", що вважаю набагато передбачуванішим. Зі сторони, (хоча це не дуже важливо; абсолютна різниця у часі незначна) IOStreams неодноразово доводили, що вони повільніші, ніж CI / O.

Я завжди стикаюся з сюрпризами під час використання IOStream.

Бібліотека здається текстово орієнтованою, а не бінарною. Це може бути першим сюрпризом: використання бінарного прапора у потоках файлів недостатньо для отримання бінарної поведінки. Користувач Чарльз Сальвія вище зауважив це правильно: IOStreams змішує аспекти форматування (де ви хочете досить вивести, наприклад, обмежені цифри для плавців) з аспектами серіалізації (де ви не хочете втрати інформації). Напевно, було б добре розділити ці аспекти. Boost.Serialization робить цю половину. У вас є функція серіалізації, яка направляє до вставок і витяжок, якщо ви хочете. Там уже є напруга між обома аспектами.

Багато функцій мають також заплутану семантику (наприклад, отримати, отримати лінію, проігнорувати та прочитати. Деякі витягують роздільник, деякі не роблять; також деякі встановлюють eof). Далі дехто згадує назви дивних функцій при реалізації потоку (наприклад, xsputn, uflow, underflow). Все стає ще гірше, коли використовуються варіанти wchar_t. Wifstream робить переклад у багатобайтовий, тоді як wstringstream цього не робить. Бінарний введення / вивід не працює з поля wchar_t: у вас є перезаписати codecvt.

Буферизований введення-виведення (тобто FILE) не настільки потужний, як його аналог C ++, але більш прозорий і має набагато меншу інтуїтивно зрозумілу поведінку.

І все-таки кожен раз, коли я натрапляю на IOStream, мене привертає до нього, як моль, щоб розпалювати. Напевно, це було б добре, якщо якийсь справді розумний хлопець добре погляне на загальну архітектуру.

Я не можу не відповісти на першу частину питання (Хто це зробив?). Але на нього відповіли в інших постах.

Що стосується другої частини запитання (Добре розроблений?), Моя відповідь - це гучне "Ні!". Ось невеликий приклад, який змушує мене з невірою хитати головою:

#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;
}

Вищевказаний код створює нісенітницю завдяки iostream дизайну. З якихось причин, які я не розумію, вони бачать uint8_t байти як символи, тоді як більші цілісні типи трактуються як числа. Кед поганий дизайн.

Я також не можу придумати це виправити. Тип може бути плаваючим чи подвійним натомість ... тож команда "int", щоб дурний iostream зрозумів, що числа, не символи, це тема не допоможе.

Після отримання голосового відмови на мою відповідь, можливо, ще кілька пояснень ... Дизайн IOStream є хибним, оскільки він не дає програмісту засобу заявити, як обробляється елемент. Реалізація IOStream приймає довільні рішення (наприклад, трактування uint8_t як знаку, а не байтового числа). Це вада дизайну IOStream, оскільки вони намагаються досягти недосяжного.

C ++ не дозволяє класифікувати тип - мова не має можливості. Не існує такого поняття, як is_number_type () або is_character_type (), який IOStream міг би використати, щоб зробити розумний автоматичний вибір. Ігноруючи це і намагаючись піти від здогадки, це вада дизайну бібліотеки.

Припустимо, printf () однаково не зможе працювати в загальній реалізації "ShowVector ()". Але це не привід для поведінки iostream. Але дуже ймовірно, що у випадку printf () ShowVector () буде визначений так:

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

Як і в інших відповідях, у іонів потоків C ++ є багато недоліків, але я хотів би зазначити щось у його захисті.

C ++ практично унікальний серед мов для серйозного використання, що робить змінний ввід і вихід простим для початківців. В інших мовах введення користувача, як правило, включає типи примусу або форматів рядків, тоді як C ++ змушує компілятор виконувати всю роботу. Це багато в чому стосується випуску, хоча C ++ не настільки унікальний у цьому плані. Тим не менш, ви можете добре відформатувати введення / виведення в C ++, не розуміючи класів та об'єктно-орієнтованих понять, що є педагогічно корисним, і не потребуючи розуміння синтаксису формату. Знову ж таки, якщо ви навчаєте початківців, це великий плюс.

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