Хотите ли Вы в этом разбираться?

[_Bers]

Начиная от курла: http://curl.haxx.se/ и
http://lacewing-project.org/
http://pocoproject.org/
http://www.alhem.net/Sockets/
http://www.w3.org/Library/
и заканчивая каким нибудь ACE.

Мне asio очень нравиться и я пользуюсь только им, но на аналогичные решения посматриваю, если они мне попадаются.

Спасибо. Я сохранил себе ссылочки

[_Bers]

Я сторонник такого кода, который может понять любой человек с помощью книг и/или помощи. А итераторы, как я убеждаюсь на своём опыте, требуют больше практики и меньше теории

Сложность кода слагается из различных ингредиентов. Например, таких как: синтаксическая сложность, алгоритмическая, архитектурная, и тп.

Синтаксическая - оказывает наименьшее влияние.

Кстати, я видел код, который не содержал никаких "технологических штучек".
Если взять отдельно взятую функцию - синтаксис понятный и узнаваемый.
Вот только что они делают не совсем понятно, потому что алгоритмическая сложность равномерно размазалась по всему проекту.
Что бы понять алгоритм одной функции, нужно было знать детали о других функциях.
Тоже самое касалось архитектуры.

Что бы понять такой код, потребовалось потратить время на изучение: что оно делает, и как она это делает.
Для этого сначала логгировал стек вызовов функций, что бы проследить "что делает".
И только потом заглядывал в пошаговой отладке вовнутри, что бы понять "как делает".
Учитывая значительный объем кода, это все заняло немало времени.

Исследование более "технологического", но более лаконичного, сжатого в объеме кода обходится быстрее.

А итераторы: что такого сложного вы в них находите?

Найдите десять отличий:
 http://rextester.com/LDUG16618

Код:

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

int main()
{
    cout << "Hello, world!\n";

    const int ar[]={1,2,3,4,5,6};    
    const vector<int> vec(ar, ar+6);
    
    {
        const auto beg = ar+1;
        const auto end = ar+4;
        for(auto it = beg; it!=end; ++it)
            cout<<"it = "<<*it<<endl;
    }
    cout<<"-------\n";
    {    
        const auto beg = vec.begin()+1;
        const auto end = vec.begin()+4;
        for(auto it = beg; it!=end; ++it)
            cout<<"it = "<<*it<<endl;
    }

}

[Old]

Если используются объекты и классы - это уже в любом случае ООП.

Это большое заблудение: "я написал в своей программе class, значит я автоматически пишу ОО-программу". Это совсем не так. Так же как и "язык C++ это С с классами". Это два совершенно разных языка, отличающимися с самого начала - с момента проектирования программы.
Скажите, вот вы взяли программу на С и стали в ней использовать контейнер вектор, стала ли она от этого объектно-ориентированной?
Я уже несколько раз писал на форуме, чем ОО подход отличается от процедурного. Кстати, очень легко можно писать ОО-программы на С, так-же как процедурные на С++.
И очень хорошо расставляет в голове эти все вещи Гради Буч. Если не читали обязательно прочтите.

Принципы Ноймана никто не отменял, поэтому написание методов не может быть иным, кроме как "классический процедурный подход", как вы это называете.

Ну и что? Что из этого, по вашему, следует, что ООП не существует?

Процедурное программирование в Qt, в принципе не возможно. Даже при написании консольных приложений.

Еще одно заблуждение.
Если вы все процедуры поместите в класс MainWindow и назовете их методами, то ваша программе не станет от этого объектно-ориентированной.

[Bepec]

И на С можно писать объектно ориентированно при помощи процедур. Это подход, а не конструкции языка.

to _Bers итераторы std мне понятны и просты. Итераторы аля те, что привёл ТС - непонятны.

[Old]

И на С можно писать объектно ориентированно при помощи процедур. Это подход, а не конструкции языка.

Точно.
Причем подход даже не к самому кодированию на языке, а раньше, к проектированию.

to _Bers итераторы std мне понятны и просты. Итераторы аля те, что привёл ТС - непонятны.

Это потому, что вы не захотели разобраться. Вам проще сказать себе: "нет, мне это не надо".
На самом деле это они же, те самые простые итератора, только с дополнительными фокусами.

[Igors]

Потом Вы также допишите и CArticle::Read, CBooklet::Read, CInbook::Read, CIncollection::Read и так до кучи по всему списку..
А далее, дополнительно к Read нужно будет дописывать не только ReadTitle и ReadAuthor, но и другие не тривиальные аналогичные методы:
ReadNote, ReadAnnote, и т.д. до кучи..

Совершенно верно, допишу. Если чтение однотипно - обобщу. Нет - переживу.

В итоге у вас получается 100500 дополнительных классов и монстрообразные switch конструкции на 100500 строк.. И в случае чего: ищи switщи потом.. или ещё хуже дописывай новоиспечённый тип..

Классов там и десятка не наберется. Switch-ей тоже. А дописывать новый тип придется всем. И добавить это в switch куда легче чем ковыряться в итераторах.

А кто Вам сказал, что у вас будет возможность работать с файлом? Например у вас на входе string.. Подождите, я угадаю: напишите ещё один Reader? Парсер ничего не должен знать ни о каких ридерах..

Это утверждение безосновательно. Чем плохо если есть возможность работать строка за строкой? Наоборот хорошо, тем более если интересующая информация в виде "вкраплений" в большой документ.

Да, это действительно смешно) До слёз)
...
Вобщем, грустно всё это(

Возможно именно это чаще всего отталкивает от буста - его зашкаливающая переоценка тех кто "прикоснулся к прекрасному". Др решения и в подметки не годятся. Те кто не юзает дуст - жалкие велосипедисты Только вот результатами это не подтверждается. Более того - часто все наоборот. Я уверен: делали бы Вы "в стиле начинающего" - все давным-давно было бы готово и уже забыто. А так Вы до сих пор копаетесь в подробностях итератора. Ну и вообще "задирать нос" нехорошо  

[xokc]

Это потому, что вы не захотели разобраться. Вам проще сказать себе: "нет, мне это не надо".

Так об этом-то и речь! До тех пока я не пойму, что мне это действительно надо, зачем мне в этом разбираться?
Только ради приобщения к касте суровых мужиков программистов, непременно использующих итераторы для всякого последовательного обхода коллекции?

[Old]

Так об этом-то и речь! До тех пока я не пойму, что мне это действительно надо, зачем мне в этом разбираться?

А как вы сможете понять, что "оно вам очень надо", если не прикоснетесь к этому?
Вот вы решаете задачу, так как привыкли и делали это много раз, но вы можете не догадываться, что эту же задачу можно решить красивее, универсальный и короче, просто потому что не смотрите по сторонам. И это очень грустно, потому что прогресса нет.
Я лезу во все, что мне попадается, и думаю как и когда мне это может пригодиться. В дальнейшем, я перебираю варианты подходов к решению, проверяю, гоняю тесты и принимаю решение. Обратите внимание, я говорю именно о подходах, а не о готовых решениях и библиотеках.

Вот пример, разбор сложного тестового формата.
Процедурный подход превратит код в ад (switch & if) даже если придется обрабатывать несколько десятков тегов, а если еще и будут зависимости, что один тег должен идти обязательно после другого, а тот  перед третьим, то понять и сопровождать это будет не возможно.
ОО подход, упростит решение, за счет того, что обработчики тегов будут независимыми объектами, упрятанными в разные классы + он будет легко расширяем, просто добавлением и регистрированием новых объектов-обработчиков.
А подход с boost.spirit, это третий подход, позволяющий описать лексические правила разбора потока (как в том же flex) и задать при необходимости правила, что делать с данными при разборе. Он сам будет проверять правильность источника по этим правилам, сам будет вызывать обработчики данных и т.д. Этот подход позволит значительно упростить разработку и сопровождение такого проекта, добавлять и модифицировать правила очень просто.

Вот три подхода, на самом деле их еще больше. Но если вы всегда пользовались первым и не интересовались, а как это еще можно решать, до остальных вариантов вы можете не дойти никогда.
А представьте, что вам поставили задачу разбора и проверки на отсутствие ошибок исходников того же C++? Кто сможет реализовать такое с процедурным подходом?

[Bepec]

У меня нет задачи под итераторы с фокусами. Тупо нет. Есть похожие задачи, но их архитектура не требует никаких итераторов с фокусами.
Чтобы понять бустовские нужно дня два сидеть и разбираться, набрасывать проектики и вот... в конце концов понять, что велосипед был проще? Увольте.
Вот возникнет задача в которой велосипед не будет справляться, или будет справляться плохо - тогда буду искать другие решения. Ведь при написании велосипедов я узнаю больше, чем при использовании буста

[Old]

У меня нет задачи под итераторы с фокусами. Тупо нет. Есть похожие задачи, но их архитектура не требует никаких итераторов с фокусами.
Чтобы понять бустовские нужно дня два сидеть и разбираться, набрасывать проектики и вот... в конце концов понять, что велосипед был проще? Увольте.
Вот возникнет задача в которой велосипед не будет справляться, или будет справляться плохо - тогда буду искать другие решения. Ведь при написании велосипедов я узнаю больше, чем при использовании буста

Блин, а кто говорит про буст?
Я говорю о разных подходах к решению. У вас нет задач под итераторы с фокусами, потом что вы не знаете, что они могут уметь дополнительные фокусы, а не потому, что их нет на самом деле. Вот и выходит, что вы всегда будете решать задачу одним методом, который знаете.

Это заблуждение, что при написании велосипеда, вы узнаете больше. Вы будете из раза в раз использовать QString и его split, ну может еще регулярку добавите. И каждое новое решение ничем не будет отличаться от старого, только именами тегов и их обработчиков.

[xokc]

А как вы сможете понять, что "оно вам очень надо", если не прикоснетесь к этому?
...
Но если вы всегда пользовались первым и не интересовались, а как это еще можно решать, до остальных вариантов вы можете не дойти никогда.
А представьте, что вам поставили задачу разбора и проверки на отсутствие ошибок исходников того же C++? Кто сможет реализовать такое с процедурным подходом?

Ну для начала, я не говорил, что принципиально не использую современные техники программирования. Я говорил, что не гонюсь за ними до тех пор, пока не не осознаю, что с ними моя задача не решится "лучше" (легче, компактнее, быстрее, дешевле и т.п.). Предвосхищая очередной аргумента в стиле "откуда знаешь если сам не пробовал", процитирую классиков "Не обязательно пробовать г...но, чтобы понять каково оно на вкус". Несколько грубовато и неправильно характеризует объект спора, но вполне применимо к уровню аргументации.

[Old]

процитирую классиков "Не обязательно пробовать г...но, чтобы понять каково оно на вкус".

Не верный аргумент. Вы правда считаете, что все что является г..ном для вас, на самом деле г..но? Вот Igors и Верес считают итераторы г..ном, итераторы от этого становятся г..ном?
Я никого не заставляю и не навязываю, что то использовать, я просто советую смотреть по сторона и пробовать даже, на первый взгляд, безумные решения. Они могут оказаться тем что надо.

[OKTA]

Хватит уже спорить  
Удобочитаемость и скорость разработки увеличивают большинство нововведений в языке, но к сожалению ни одно еще не увеличивало скорости итоговой работы программы

[Igors]

А подход с boost.spirit, это третий подход, позволяющий описать лексические правила разбора потока (как в том же flex) и задать при необходимости правила, что делать с данными при разборе. Он сам будет проверять правильность источника по этим правилам, сам будет вызывать обработчики данных и т.д. Этот подход позволит значительно упростить разработку и сопровождение такого проекта, добавлять и модифицировать правила очень просто.

Ну а чего же "по-сухому"? Вот BitTex в рамках гуглы, для удобства привожу опять

@Book{hicks2001,
 author    = "von Hicks, III, Michael",
 title     = "Design of a Carbon Fiber Composite Grid Structure for the GLAST
              Spacecraft Using a Novel Manufacturing Technique",
 publisher = "Stanford Press",
 year      =  2001,
 address   = "Palo Alto",
 edition   = "1st,",
 isbn      = "0-69-697269-4"
}

Покажите как это распарсить спиритом, тогда и сравним. 

[Old]

Покажите как это распарсить спиритом, тогда и сравним.  

Покажите как вы это распарсите процедурно, а я покажу как это распарсить spirit.
Давайте, только то что m_ax выложил, реальный пример.