Сортировка массива qsort

[m_ax]

Код:

    std::copy(arr.begin(), arr.end(), std::ostream_iterator<int>(std::cout, " "));

А что если надо напечатать аккуратнее? Напр по 10 чисел в строке и чтобы столбики ровные. Можно ли задействовать этот крутой сынтаксыс - или придется по-народному printf ?

Не вижу проблемы..
Ещё как вариант, можно задействовать другой крутой сынтаксис:

Код

C++ (Qt)
for (auto x : arr) {
   ...
}
 

И потом, может ли ваш народный printf выводить данные, например в файл? Нет? А в osstream_iterator можно передать объект на ofstream, например, и писать данные уже в файл. Без лишних телодвижений)

[Igors]

Код

C++ (Qt)
for (auto x : arr) {
   ...
}
 

А как оно печатает?    Достаточно только это написать, что ли? 

И потом, может ли ваш народный printf выводить данные, например в файл? Нет? А в osstream_iterator можно передать объект на ofstream, например, и писать данные уже в файл. Без лишних телодвижений)

А с printf я могу ничего и не передавать, а назначить вывод в файл при запуске приложения 

[m_ax]

Код

C++ (Qt)
for (auto x : arr) {
   ...
}
 

А как оно печатает?    Достаточно только это написать, что ли? 

Ну как, как.. Как Ваша душа пожелает, так и напечатает.. И не только напечатает..

И потом, может ли ваш народный printf выводить данные, например в файл? Нет? А в osstream_iterator можно передать объект на ofstream, например, и писать данные уже в файл. Без лишних телодвижений)

А с printf я могу ничего и не передавать, а назначить вывод в файл при запуске приложения 

И на этом похоже, всё преимущество(?) и заканчивается(
Т.е. я правильно понимаю, что для Вас типонебезопасная сишная функция printf предпочтительнее стандартному механизму потоков ввода-вывода?
Вся эта концепция заложенная в основу потоков ввода-вывода, наверное, была придумана от нечего делать)
   

[Igors]

Вся эта концепция заложенная в основу потоков ввода-вывода, наверное, была придумана от нечего делать)

Какая "вся эта"   Вот Вы блеснули такой конструкцией

Код

C++ (Qt)
std::copy(arr.begin(), arr.end(), std::ostream_iterator<int>(std::cout, " "));

Которую я наблюдал тут и сям не раз. Однако сам бы писал напр так

Код

C++ (Qt)
for (size_t i = 0; i < arr.size(); ++i) 
 printf("%8d%s", arr[i], (i % 10) ? "," : "\n");
 

Ну 2 строчки вместо одной - но делает все что мне надо и проблем у меня никаких. Спрашиваю у Вас как сделать это "в современном стиле" - ответа не получаю. Что мне остается думать? Что все оте ostream_iterator<.. - дешевые понты чтобы пустить пыль в глаза. Или это не так? 

[m_ax]

Вся эта концепция заложенная в основу потоков ввода-вывода, наверное, была придумана от нечего делать)

Какая "вся эта"  

Igors, не путайте концепцию, с конструкцией)
Имеется ввиду концепция единого интерфейса при работе с потоками ввода-вывода. Фишка в том, что все операции с обычными участками ввода-вывода, т.е. файлами, консолью, блоками памяти и т.д. поддерживают единый интерфейс. И средства, которые предоставляет этот механизм и сама архитектура гораздо более удобнее, гибче и безопаснее.
Стоит ли говорить о том, что всё это семейство функций printf плохо расширяется, поскольку написаны лишь для базовых C типов?
Стоит ли мне перечислять все недостатки и потенциальные грабли от использывания printf?

Кстатии, одним из основных достоинств потоков ввода-вывода является это безболезненная адаптация к введению новых классов..

Вот Ваш пример ниже:

Код

C++ (Qt)
for (size_t i = 0; i < arr.size(); ++i) 
 printf("%8d%s", arr[i], (i % 10) ? "," : "\n");
 

Ну 2 строчки вместо одной - но делает все что мне надо и проблем у меня никаких. Спрашиваю у Вас как сделать это "в современном стиле" - ответа не получаю. Что мне остается думать? Что все оте ostream_iterator<.. - дешевые понты чтобы пустить пыль в глаза. Или это не так? 

 
А давайте представим сейчас, что массив содержит не какой-нить базовый C тип, а что-нибудь чуть более сложное..

Вы всё равно упорно будете использовать printf?

 


 

[Igors]

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

Если взглянуть более узко/практично, то оказывается что далеко не все укладывается в рамки красивой концепции.

Напр вывод на консоль бедноват (нечем форматить). При копировании в файл вероятно придется крутить индиану, а нередко и писать то чего в памяти нет - или наоборот. При выводе на др устройство возникнут свои проблемы (напр размер страницы на принтере).

С точки зрения "расширяемости" - ну при любом раскладе мою структуру за меня никто не выведет, нужно писать код для I/O. И не будет он общим для консоли/памяти/файла. Возможно Вы имели ввиду что в дальнейшем обобщать удобнее (подсовывая разные итераторы в одну схему). Ну это достижимо и с помощью операторов  >> и <<

Ну хорошо, общность так общность. Вот я хочу вывести в QIODevice (напр в QFile). Как это у Вас будет выглядеть для int и для произвольной структурки (напр всего 2 int)?

[m_ax]

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

Если взглянуть более узко/практично, то оказывается что далеко не все укладывается в рамки красивой концепции.

Напр вывод на консоль бедноват (нечем форматить). При копировании в файл вероятно придется крутить индиану, а нередко и писать то чего в памяти нет - или наоборот. При выводе на др устройство возникнут свои проблемы (напр размер страницы на принтере).

Неправда, возможности форматирования в потоках вывода очень богаты. Как минимум для потоков доступны все функции форматирования printf.
Советую почитать про такие вещи как манипуляторы (пользовательские манипуляторы), форматные флаги, поля, эффекторы и т.д.

С точки зрения "расширяемости" - ну при любом раскладе мою структуру за меня никто не выведет, нужно писать код для I/O. И не будет он общим для консоли/памяти/файла. Возможно Вы имели ввиду что в дальнейшем обобщать удобнее (подсовывая разные итераторы в одну схему). Ну это достижимо и с помощью операторов  >> и <<

Ну хорошо, общность так общность. Вот я хочу вывести в QIODevice (напр в QFile). Как это у Вас будет выглядеть для int и для произвольной структурки (напр всего 2 int)?

Для моей произвольной структурки это будет выглядеть также, как и для int) 

[Igors]

Советую почитать про такие вещи как манипуляторы (пользовательские манипуляторы), форматные флаги, поля, эффекторы и т.д.

Ну если это так просто, то почему бы Вам не тиснуть неск строк кода? Или Вы советуете то что сами не делаете? 

Для моей произвольной структурки это будет выглядеть также, как и для int) 

То же самое - предъявляем не только словеса, но и пример кода

[m_ax]

Советую почитать про такие вещи как манипуляторы (пользовательские манипуляторы), форматные флаги, поля, эффекторы и т.д.

Ну если это так просто, то почему бы Вам не тиснуть неск строк кода? Или Вы советуете то что сами не делаете?  

Хорошо, поясню на таком примере.. Предположим у нас есть массив чего-то там.. Мы хотим иметь возможность различных форматов вывода его содержимого в поток (причём не обязательно это должна быть консоль). Например выводить в виде таблицы с заданным числом колонок и разделяющими символами, или в виде треугольной матрицы или на что фантазии хватит..
И при этом нам бы ещё хотелось иметь возможность использовать эту конструкцию в таком цепочечном выражении, типа:

Код

C++ (Qt)
os << string << '\n' << array << "аляхер маляхер" << some_value << endl;
 

Для этого народ придумал такую штуку, как эффектор. пример:

Код

C++ (Qt)
template <class Container>
class Table {
public:
    Table(const Container &container, int column, const char * tab = "\t")
        : _container(container), _col(column), _tab(tab) {}
 
    friend std::ostream& operator<<(std::ostream &os, const Table &t) {
        int i = 0;
        for (const auto & x : t._container) { (++i % t._col) ? os << x << t._tab : os << x << std::endl; }
        return os;
    }
private:
    const Container &_container;
    int _col;
    const char * _tab;
};
 
...
 
std::cout << Table<decltype(arr)>(arr, 10)  << Table<decltype(arr)>(arr, 3, "...") << endl;
 
std::ostringstream os;
os <<  Table<decltype(arr)>(arr, 10) << Table<decltype(arr)>(arr, 3, "...") << "Аляхер-маляхер" << endl;
 
std::ofstream out("example.txt");
out << Table<decltype(arr)>(arr, 10)  << Table<decltype(arr)>(arr, 4, "\t") << "Аляхер-маляхер" << endl;
 
// и т.д..
 

 

И заметьте, что я могу передавать в эффектор Table как обычный C массив, так и список, вектор, array и т.д.. И выводить данные в любой поток вывода, без лишних телодвижений.

Если использовать народный printf, то код моментально бы превратился в огород..


  

[Igors]

Во всем этом нет чувства меры. Создается класс, (ну разумеется template, как же без него), привлекается новейший стандарт и.т.п. А чему же все это посвящено? Оказывается всего лишь печати по N элементов в строке. При этом до ф-ционала "допотопного" printf еще очень далеко (подложка пробелами, число знаков после запятой и др).

Вот именно за это многие (включая меня) и не любят Александреску и его птенцов - наворочено много, а дела/ф-ционала - пшик.

[m_ax]

Во всем этом нет чувства меры. Создается класс, (ну разумеется template, как же без него), привлекается новейший стандарт и.т.п. А чему же все это посвящено? Оказывается всего лишь печати по N элементов в строке. При этом до ф-ционала "допотопного" printf еще очень далеко (подложка пробелами, число знаков после запятой и др).

Вот именно за это многие (включая меня) и не любят Александреску и его птенцов - наворочено много, а дела/ф-ционала - пшик.

Нет, это Вы так говорите, пока видите лишь необходимость выводить в консоль стандартные C типы.. Достаточно чуть усложнить задачу (да даже просто сменить тип контейнера, на, например, std::list) как тут же ситуация изменится на противоположную.. Я уже не говорю о том, что Вы будете делать с Вашим printf, когда возникнет необходимость выводить данные в разные потоки.. А если ещё тип элементов контейнера изменится? 

Что касается управление форматирования, то также можно реализовать.
например число знаков после запятой, легко:

Код

C++ (Qt)
std::cout << setprecision(6) << Table<decltype(arr)>(arr, 10) << std::endl;
 

 
Помимо этого есть ещё куча манипуляторов, как с параметрами, так и без них. (И никто Вам не мешает написать свой)
Вот некоторые из них (просто перечислю, без описания):
flush, hex, oct, dec, ws, showbase/noshowbase, showpos/noshowpos, uppercase/nouppercase, showpoint/noshowpoin, left, right, internal, scintific/fixed, setbase, setfill, setw и т.д..

[Igors]

Помимо этого есть ещё куча манипуляторов, как с параметрами, так и без них.

Конечно есть, я с этим не спорю. Но все это выглядит как-то тяжеловесно, нет лаконичности и удобства простого printf, заряжаем пушку для стрельбы по воробьям

[alex312]

Конечно есть, я с этим не спорю. Но все это выглядит как-то тяжеловесно, нет лаконичности и удобства простого printf, заряжаем пушку для стрельбы по воробьям

Вот именно за это многие (включая меня) и не любят Александреску и его птенцов - наворочено много, а дела/ф-ционала - пшик.

Вы уж определитесь, спорите или не спорите, функционала пшик или наворочено  
Ну и, собственно вас никто не заставляет.

А еще есть http://www.boost.org/doc/libs/1_53_0/libs/format/doc/format.html - и компактно, и типобезопасно.

[Igors]

Вы уж определитесь, спорите или не спорите, функционала пшик или наворочено  

Я говорил что печально видеть "навороченый пшик" что, увы, часто случается с теми кто слепо следует моде 

Ну и, собственно вас никто не заставляет.

А еще есть http://www.boost.org/doc/libs/1_53_0/libs/format/doc/format.html - и компактно, и типобезопасно.

Ну так это творческое развитие идей printf

[m_ax]

Ну так это творческое развитие идей printf

Вообще то, это как раз развитие темы паттерна эффектора) И основная фишка там как раз абстрагироваться от конкретного типа данных и потока вывода..

Я говорил что печально видеть "навороченый пшик" что, увы, часто случается с теми кто слепо следует моде  

Ещё печальней наблюдать за тем, как некоторые ретрограды изобретают немыслимые костыли, а потом всячески ищут оправдания своим архитектурным изыскам)