C, простейшая задача

>> Парсинг текста к вводу-выводу отношения не имеет никакого.

А что, кто-то заставляет? Никто не мешает парсить полученный из потоков текст (или бинарные данные) отдельно. Никто даже не заставляет использовать iostream'ы - можно взять C'шный io или то что предоставляет операционная система. Только часто ли это нужно?

> BTW: Я бы конечно считал ввод при помощи getline и распарсил при помощи pcre.

Я тебе задачку про матрицу дал пару флеймов назад. Или это тебе опять "не нужно"?

господа, вы все ошибаетесь!

>> BTW: Я бы конечно считал ввод при помощи getline и распарсил при помощи pcre.

>Я тебе задачку про матрицу дал пару флеймов назад. Или это тебе опять "не нужно"?

Ложь. Во всех флеймах про iostream ты стабильно слил.

> Это не задача C сделать это красиво, его задача - сделать быстро. То, что ты сделаешь с iostream и stl будет гораздо медленнее, а если делать быстро, разницы в размере особо не будет.

Достаточно легкомысленное заявление. STL в большинстве случаев уделывает C-шную библиотеку по производительности, в зависимости от ситуации, может быть от нескольких процентов до нескольких разов быстрее.

Другое дело iostream, но и тут, надо сказать, у C++ либы есть преимущество: плюсовый код на этапе компиляции "парсит форматную строку", т.е. по типам аргументов, понимает и инлайнит нужный код, для чтения именно uint32_t, а С-шному коду прийдется еще парсить форматную строку на каждый читаемый uint32_t.

В сумме, не факт, что C++ окажется медленней на вводе-выводе, -- у него есть вещи, которые его тормозят, а есть и вещи, которые будут работать в разы быстрее чем в C.

>> Это не задача C сделать это красиво, его задача - сделать быстро. То, что ты сделаешь с iostream и stl будет гораздо медленнее, а если делать быстро, разницы в размере особо не будет.

>Достаточно легкомысленное заявление. STL в большинстве случаев уделывает C-шную библиотеку по производительности, в зависимости от ситуации, может быть от нескольких процентов до нескольких разов быстрее.

Во-первых оно будет в полтора-два раза медленнее - все эти инлайны в манипуляторах только приведут к раздуванию кода. Во вторых это не то место, где программы тормозят и поэтому всех устраивает скорость перла и питона для таких вещей.

PS: Где вас таких клонируют?

>> Я тебе задачку про матрицу дал пару флеймов назад. Или это тебе опять "не нужно"?

> Ложь. Во всех флеймах про iostream ты стабильно слил.

С тобой разговаривать невозможно из-за твоей привычки перевирать всё согласно твоему внутреннему состоянию.

>>> Я тебе задачку про матрицу дал пару флеймов назад. Или это тебе опять "не нужно"?

>> Ложь. Во всех флеймах про iostream ты стабильно слил.

>С тобой разговаривать невозможно из-за твоей привычки перевирать всё согласно твоему внутреннему состоянию.

Да нет у меня колебаний внутреннего состояний. Я как считал так и считаю что парсинг входных данных - это довольно сложная задача, которую лучше доверить специализированным библиотекам. С другой стороны, интерфейс стрима должен быть простым - прочитать чанк/записать чанк. Я уже не прошу об асинхронном API, который действительно улучшил бы перформанс ввода-вывода.

> Во-первых оно будет в полтора-два раза медленнее - все эти инлайны в манипуляторах только приведут к раздуванию кода. Во вторых это не то место, где программы тормозят и поэтому всех устраивает скорость перла и питона для таких вещей.

Хорошо, если ты на этом настаиваешь, -- привети тесты, в качестве примера, доказывающие твою правоту.

> PS: Где вас таких клонируют?

Мы не раскрываем эту информацию.

>> Во-первых оно будет в полтора-два раза медленнее - все эти инлайны в манипуляторах только приведут к раздуванию кода. Во вторых это не то место, где программы тормозят и поэтому всех устраивает скорость перла и питона для таких вещей.

>Хорошо, если ты на этом настаиваешь, -- привети тесты, в качестве примера, доказывающие твою правоту.

Месяца три назад уже тестировали - iostream слил stdio в два раза.

> Месяца три назад уже тестировали - iostream слил stdio в два раза.

Пруфлинк?

>> Пруфлинк?

+1, тоже интересно посмотреть.

о том что iostream медленнее printf не говорил только ленивый :)
это плата за типобезопасность. насколько оно будет медленнее - зависит от компилятора,
реализации STL и видимо ключей компиляции.

#include <stdio.h>

int main()
{
    int day = 1, month = 2, year = 3, hour = 4, minute = 5, second = 6, milliseconds = 7;

    for ( int i = 0; i < 20000000; i++ )
    {
        printf("%02d/%2d/%04d %02d:%02d:%02d.%03d", day, month, year, hour, minute, second, milliseconds);
    }

    return 0;
}

#include <iostream>
#include <iomanip>
using namespace std;

int main()
{
        int day = 1, month = 2, year = 3, hour = 4, minute = 5, second = 6, milliseconds = 7;

        for ( int i = 0; i < 20000000; i++ )
        {
                cout << setfill('0') << setw(2) << day << '/'
                         << setfill(' ') << setw(2) << month << '/'
                         << setfill('0') << setw(4) << year << ' '
                         << setw(2) << hour << ':'
                         << setw(2) << minute << ':'
                         << setw(2) << second << '.'
                         << setw(3) << milliseconds;
        }

        return 0;
}

C: time ./a.out > /dev/null
real    0m42.044s
user    0m32.798s
sys     0m0.036s
C++: time ./a.out > /dev/null
real    1m9.992s
user    0m55.215s
sys     0m0.044s

>> Месяца три назад уже тестировали - iostream слил stdio в два раза.

>Пруфлинк?

Скотт Мейерс в Effective C++ проводил такое тестировавние, и лучшие реализации iostream были раза в два хуже по всем критериям (использование памяти, перформанс, размер кода и пр). Худшие - на порядки. Можно допустить, что компиляторы стали с тех пор лучше. Но и C++ stdlib стала жирнее.

PS: Давайте определим такой регламент: я плююсь на Си++, а пруфлинки что я не прав добываете вы.

>это плата за типобезопасность.

Статиическая типизация в теории дает прирост перформанса. Ради нее по идее все это и делается.

от части, скорость может поднять std::cin.sync_with_stdio(false);

> Скотт Мейерс в Effective C++ проводил такое тестировавние, и лучшие реализации iostream были раза в два хуже по всем критериям (использование памяти, перформанс, размер кода и пр). Худшие - на порядки. Можно допустить, что компиляторы стали с тех пор лучше. Но и C++ stdlib стала жирнее.

В каокой части самой книги?

Стоит заметить, что изначально речь шла об эффективности как STL так и iostream-ов, и если последние да, могут и сливать, хотя сильно зависит от реализации, то первая, STL, очень делает С-ную либу по производительности, о чем неоднократно Майерс и пишет.