А вот давайте спросим у Vlad'a, почему же он боится написания своего сложного кода? ;-) И боится ли он вообще?
Писать сложный код намного проще, чем простой - думать меньше надо
Не пишу я его потому что это дорого:
- его сложнее тестировать
- его сложнее понимать и менять потом (мое любимое сопровождение, да)
- его надо документировать
Конечно в момент написания можно и не думать об этих пунктах - тогда вообще халява
Последние несколько дней решал такую задачу:
Есть интеркативная форма. Есть вычисления на сервере. Форма отображается результаты вычислений (результаты совершенно разного вида, заранее неизвестного). Нужно, собственно, обеспечить интеркативность - пока там чего-то вычисляется, форма должна оставаться интерактивной (до какой-то степени). Короче, ближайшая аналогия - это веб браузер, который отображает страницу по мере ее загрузки.
Ну понятно, что появляется многопоточность. Тема сама по себе сложная, кроме того я с ней редко сталкиваюсь в повседневной практике, поэтому было над чем поразмыслить. Из дополнительных особенностей - результаты уже запущенных вычислений надо уметь игнорировать (форма перешла в другое состояние или просто была перезагружена/закрыта). Кроме того, надо уметь определить, что какие-то вычисления еще не завершились и подождать их завершения (чтобы форма могла перейти в следующее состояние).
В результате нескольких итераций родился один компонент с интерфейсом из нескольких методов (можете тоже поразмыслить и пределожить возможные варианты - посмотреть насколько мысли сходятся). Из ~5 комментариев типа "здесь мы лочим мьютекс потому что... а здесь не лочим потому что..." остался один - потому что я смог упростить код так, что одни моменты стали очевиднее, а другие моменты "покрыть" тестами (да, юнит тестик тоже появился вместе с компонентиком). Оставшийся один комментарий - действительно тонкий момент, который я не смог покрыть тестом (высокая "конкурентность" между двумя действиями, возможная проблема не репродьюсится даже на сотне потоков и множестве итераций). Возможно при большем опыте я бы смог выразить этот момент в коде, но пока остается только комментарий
Сам компонент не имеет зависимостей от других компонентов (формы). Точнее использует только один абстрактный коллбэк (который в итоге цепляется к форме, а в юниттесте легко подставляется заглушка).
Понятно, что для таких задач никогда не будет ничего готового в стандартной библиотеке. Ну разве что там будет компонент "веб браузер"
С другой стороны, я не хочу каждый раз начинать с нуля: я хочу иметь в библиотеке потоки, примитивы синхронизации и даже "очередь". Иначе 90% времени я буду тратить на совершенно неинтересную фигню типа особенностей condition variables на конкретной платформе (да, код писан/тестирован был на винде, но сразу заработал на маке).
Да, каким боком мне помогли бы здесь заинтриговавшие меня карты памяти - пока не представляю. Подозреваю, что это просто еще более высокий уровень системы.
