AHTOH_LЧем вам так поможет список классов в отдельном файле?
В отдельном файле не обязательно, хотя фича имеет свои плюсы, а вот в отдельном месте - удобно. Когда, например, задача решается взаимодействием двух-трёх базовых классов, каждый из которых имеет наследников, крайне удобно понять общую артитектуру модуля просто открыв файл и пар раз нажав PageDown. Аналогично, когда ищешь что-то, что плохо помнишь - стартовая точка компактна и под рукой.

AHTOH_LЕсли мне нужен будет список классов я посмотрю его в отдельном окне
Я понимаю, что логика "если мне потребуется вторая конечность, я могу взять к мешку ещё и костыль" практически неопровержима, поэтому не собираюсь тратить время на теоретическую беседу с человеком, устриц не пробовавшим. Есть люди, например топикстартер, которым это удобно. Какой смысл приходить к ним и устраивать бучу с криком "да нафиг вам это надо!?"

White OwlИсключения не удобны. Если их использовать так как предлагают в учебниках - они прячут источник проблемы. А если в каждом потенциально опасном месте вешать обработчики исключения то код превращается в сплошную обработку исключений. ... Коды возврата намного удобнее - когда надо ловишь, когда не важно - игнорируешь. Причем ловишь их всегда именно там где ошибка произошла
Коды ошибок и пользовательские исключения семантически эквивалентны. Любой алгоритм, который записывается с помощью одного метода, записывается и с помощью другого; вопрос лишь в том, насколько качественный код получается в том и другом случае.

Можно привести примеры, когда удобнее каждый из вариантов. В принципе можно назвать реальные задачи, для которых коды ошибок окажутся в среднем удобнее, но в общей массе таких крайне мало. Причины этого следующие:

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

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

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




Ну и наконец, у кодов ошибок есть третья неприятная особенность:

3. Разработка с использованием кодов ошибок сама по себе склонна к ошибкам и требует повышенного внимания и дополнительного времени и при разработке, и при тестировании. При использовании исключений вполне можно идти методом постепенного улучшения; реализовать самые общие обработчики, а затем по мере необходимости уточнять реализацию в соответствии с реальными потребностями; риск при этом лишь в том, что некая ситуация будет обработана недостаточно хорошо. При использовании кодов ошибок правильный код надо писать везде, сразу и полностью, в противном случае программа скорее всего испортит данные и/или выдаст кривые результаты.


White OwlА в языках типа Java которые требуют обязательной обработки исключений сложно сделать игнорирование ошибки,
Согласен, это противно и дурацкая идея. К счастью, в Java есть RuntimeException, позволяющий писать сравнительно вменяемый код с небольшим оверхедом.

White OwlА шаблоны это источник гигантских проблем для библиотек. Вчера ты написал шаблон, написал класс использующий этот шаблон, скомпилировал его, положил объектный файл в библиотеку. Сегодня ты подправил шаблон, написал второй класс использующий его и скомпилировал, тоже в библиотеку.
Имхо проблема здесь не в шаблонах, а в доведении идеи раздельной компиляции до абсурда.

White OwlНо самая главная проблема шаблонов это то что в них реальной нужды нет.
То, в чём нет реальной нужды, будет редко использоваться на практике. Скажем, на сегодня в этой роли выступают коды ошибок.

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

White OwlА тебе не кажется что ты сам себе противоречишь? Если у тебя в перемешку идут команды на запись нужного файла и на запись лога
А тебе не кажется, что для того, чтобы придумать это возражение, тебе пришлось свести воедино два абзаца, прямо таки номерами обозначенные как совершенно разные, независимые ситуации? Отвечать на такую манипуляцию смысла нет... хочешь - подумай ещё раз, хочешь - считай, что прав.

White OwlВовсе нет. Дублирования кода нет - единственное что дублируется это "if error then"
Да нет, есть и весьма часто. Например, необходимость подчистить текущее состояние для продолжения работы после обработки ошибки. Например, одинаковые error_handler_of_this_type в разных подпрограммах. Но даже если дублируется лишь if error then return - оно чертовски достаёт, когда это каждая вторая строчка программы. Это dumb code.

White OwlЭто очень странное возражение. То есть писать плохо это хорошо, а сразу писать хорошо это плохо? мдя...
Если отбросить религиозные воззрения, то "то есть писать хорошо и легко это хорошо, а писать хорошо с большими усилиями, требованиями к внимательности и лёгкостью допущения ошибок - не столь хорошо".

White OwlХе-хе-хе... И это ты говоришь человеку принципиально не использующему исключения? :)
Ну я знаю много принципиально творимых глупостей. Скажем, один мой знакомый айтишник принципиально отрубает у себя javascript и flash, а всех, кто делает сайты с использованием этих инструментов, называет самое мягкое мудаками, мешающими ему полноценно пользоваться интернетом.

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

White OwlЯ знаю только одну группу алгоритмов - управление структурами данных.
Назову самый что ни на есть классический пример - обобщённая функция вычисления интеграла с подстановкой конкретного метода вычисления (прямоугольников, трапеций итп). Уверен, Вы не могли о нём не слышать. А так.... тысячи их.

White OwlКакие типы данных ты используешь для вычисления интеграла?
Абстрактные :)

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

egorychдостаточно 2х типов, у которых одинаковый интерфейс,
С учётом шаблонных функций в общем-то иногда можно и без одинакового интерфейса.

White OwlВот это как раз тот случай, когда лично я бы наплодил бы несколько уникальных "решателей" для каждого из типов. Потому что этих типов очень малое число - действительные и комплексные. И я на 100% уверен что ....
Позволю себе спросить - а каков вообще Ваш опыт с шаблонами (не генериками)? Просто, честно говоря, по разговору складывается ощущение, что Вы плохо представляете себе их возможности и применение.