Достала избыточность С++

:

imageПривет Хабр,
Меня вводит в ступор С++. Вот просто, зависаю над монитором, смотрю в окно, попиваю чай… И начинаю жалеть за бесценно проведенные годы за изучением стандарта С++, попытками написать свой фронт-энд компилер. Эти мудреные книжки С++ In Depth. Как же я негодовал, когда не понимал кода из книги Александреску. Как записывал все постулаты Страуструпа и иже с ними. Зачем? Вот спрашиваю себя, зачем я теперь все это знаю. Более, я хочу сказать, что этот язык нещаден для гуру, не с медицинской, не с экономической точки зрения! Он не оправдывает усилий, вложенных в его изучение — раз. На практике, он экономически не выгоден — два. И нервные клетки подтвердят, что сопровождать чужой плюснутый код — бывает опасно для здоровья -три. Пусть тут будут рандомно разбросаны метафоры, пишу как есть, из опыта.

Вот, например, из-за зубренных постулатов: объекты в методы передавать как константные ссылки.
Да, я пока пишу

Status DetectionManager::GetDetectionStatus(const FileScanTask &fileTask) const {
    m_detector.GetDetectionStatus(fileTask);
}

Забываю про задачу как таковую. А в голове крутится: надо чтоб не было класса Бога, поэтому делегируем обязательства, надо передавать объект по костантной ссылке, метод тоже должен быть const, а вдруг нам нужно будет изменять что-то… ммм… тогда объявлю m_detector как mutable. Но тогда моего коллегу джуниора может это смутить… что-же делать.
Создать второй метод? Так, члены должны объявляться с префиксом 'm_', чтобы не было. А может стоит еще обозначить что метод генерирует исключения? Добавить throw к нему?
Будет яснее, но опять же джуниор…
Это простой пример, где решение задачи, напрочь смывается из памяти этими-всеми «плохой тон программирования».

Вот еще подборочка, для любителей хорошего тона:
С членами классов работать через set/get методы. Даже если у вас класс Exception с одним членом reason, нам нужно, по правилам хорошего тона, объявить конструктор, метод Get, метод Get const, можно и Get const volatile, а вдруг пригодиться? А как насчет пойти дальше, сделать все методы приватными и добавлять по friend'у, кто их использует? Ах да, не забудь про виртуальный деструктор!

Далее в порядке бреда от малого до великого:
— Никаких goto. Лучше do { break; } while(0); От этого суть глобально меняется.
— Параметры макросов в скобках. А вообще макросы нельзя употреблять! Это же нарушает типизацию.
— Никаких указателей, даже если очень хочеться. Только умные, с 4-мя шаблонными параметрами.
— Никаких глобальных переменных. Низя!

Впрочем, стоит почитать Скота Мейрса, Александреску, наших авторов, для продолжения списка. Просто лень тянуться на полку… Я не против знаний, я против их переизбытка применительно к задаче.

Еще из эстетствующего:
— Не должно быть больше 4 вложенных конструкций. А если очень надо? — Разделяй на функции. Причем протитип в хэдер, реализацию рядом с основной функцией.
— Множественное наследование — плохо. Зато виртуальное наследование, спецификаторы
доступа при наследовании, и какие они будут в наследуемом классе — надобно знать. Очень нужная вещь… на собеседованиях
— reinterpret_cast, static_cast, const_cast. Почему нет private_to_public_in_case_exception_cast?

Далее, такие записи:
— Это мы получаем при поиске в map'е. Детям нельзя такое преподавать.

typedef typename _STD tr1::conditional<
        _STD tr1::is_same<key_type, value_type>::value,
        const_iterator,
        _Tree_iterator<_Mybase> >::type iterator;

— А как вам такой пул потоков. Это при том, что задать нотификатор о завершении потока, или приостановить поток — проблемно. В том же WinApi, делается в 2 функции. А тут мета политики! Причем в TODO еще одна на подходе. Забыли про случай, когда шнур из розетки вылетает.

template <
    typename Task                                   = task_func,
    template <typename> class SchedulingPolicy      = fifo_scheduler,
    template <typename> class SizePolicy            = static_size,
    template <typename> class SizePolicyController  = resize_controller,
    template <typename> class ShutdownPolicy        = wait_for_all_tasks
  > 
  class thread_pool

Скучно стало в академ кругах, и ай да еще:
Тут тебе и rvalue-ссылки &&, и constexpr, и шаблоны с переменным количеством параметров. Без этого ж не кодилось.
Полный список здесь.
Кто это все осилит? Это несколько лет непрерывных проб и ошибок, пока терпения хватит. Из C++ 0x только auto и лямбды в параметрах STL-алгоритмов, на практике пригодились.

Все остальное — это переизбыток и многословность!

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

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

Удачи!