Моё почтение, уважаемые. Не так давно я выкатил статью про проблемы C++. Точнее про проблемы программистов с языком C++, а так же с другими языками, которые якобы все из себя замечательные. Мой очерк был сварганен под влиянием статьи одного МГУшного деятеля, который потрудился измарать кучу бумаги написав, какой C++ стремный язык, но не потрудился накопать достаточно нормальных примеров и вычистить ошибки в своей статье. Мой ответный удар не остался без внимания и на его сайте Борескова за 15 апреля сего года бал подвешен очередной список разоблачений. Новый список оказался ещё смешнее чем предыдущий, ибо теперь он практически полностью состоит из заблуждений и глупостей либо из вещей, которые, в общем-то, не являются очень большой проблемой C++, а иногда являются проблемой не одного только C++. Короче, аргументы скучные, наезды неинтересные. Ни тебе харкания кровью в оппонентов, ни вырывания меха из жопы. Ни-че-го. Из приведенных там ссылок внимания заслуживают только две — раз и два. Вот некоторые представленные там тезисы и замечания...
Моё почтение, уважаемые. Не так давно я выкатил статью про проблемы C++. Точнее про проблемы программистов с языком C++, а так же с другими языками, которые якобы все из себя замечательные. Мой очерк был сварганен под влиянием статьи одного МГУшного деятеля, который потрудился измарать кучу бумаги написав, какой C++ стремный язык, но не потрудился накопать достаточно нормальных примеров и вычистить ошибки в своей статье. Мой ответный удар не остался без внимания и на его сайте Борескова за 15 апреля сего года бал подвешен очередной список разоблачений. Новый список оказался ещё смешнее чем предыдущий, ибо теперь он практически полностью состоит из заблуждений и глупостей либо из вещей, которые, в общем-то, не являются очень большой проблемой C++, а иногда являются проблемой не одного только C++. Короче, аргументы скучные, наезды неинтересные. Ни тебе харкания кровью в оппонентов, ни вырывания меха из жопы. Ни-че-го.
Из приведенных там ссылок внимания заслуживают только две — раз и два.
Вот некоторые представленные там тезисы и замечания:
«Иногда очень хочется иметь возможность компилировать C++ в "безопасном" режиме, с контролем корректности индексов и указателей, с печатью полного stack trace при обнаружении каких-либо проблем.»
Никто не мешает этого делать, M$ давно выпустила managed C++, как видно из названия весь из себя «managed» и весь из себя «безопасный». Оно?
«В самом начале исключений в C++ не было. Затем поддержка исключений появлялась в разных компиляторах в разное время. Затем появился стандартный класс std::exception в качестве базового для всех исключений. Все это привело к тому, что разные C++ библиотеки используют разные подходы к диагностированию и обработке ошибок Из-за этого при разработке C++ с применением разных библиотек приходится использовать в коде разные подходы к обработке ошибок. Это утомительно. К тому же на фоне современных языков это еще и выглядит напрасной тратой времени.»
Нет не приходится. Нормально спроектированная и нормально реализованная система базируется на некотором фреймворке собственного производства. Этот фреймворк состоит из нескольких слоев. Причем этих слоев тем больше чем лучше он спроектирован. Database abstraction layer, File system abstraction layer и так далее. Выкрутасы любой сторонней библиотеки прячутся на одном из слоев вашего фреймворка и для пользователей фреймворка становятся абсолютно невидны, будь то исключения, коды возврата или ещё что-нибудь.
К любому сколь угодно кривому интерфейсу можно написать любой сколь угодно удобный декоратор. Это аксиома. А вот если подключать сторонние библиотеки в слой бизнес логоки, то таки да, вы очень быстро разведете там говнище. Причем это не зависит от выбранного языка. Это произойдет в C++, и в Джаве и ДоДиезе. Поминится в одном моем проекте помимо прочих было две функции. Одна представляла из себя pop3 сервер, а вторая smtp сервер. Обе сделаны на базе MFCшных текстовых сокетов. Расширение сознания было полное )).
«Тем не менее, многие качества шаблонов явились всего лишь побочным явлением их дизайна. В частности метапрограммирование на шаблонах. Мне кажется это ненормальным. Либо шаблоны нужно было ограничить, либо расширить так, чтобы не нужно было писать вагоны кода для создания класса IsFunction или FunctionReturnType. Ничего подобного благодоря затянутым процедурам стандартизации языка не произошло.»
Да, затянутая процедура стандартизации это проблема.
«Я просто не считаю нормальным необходимость писать сотни строк шаблонного кода для того, чтобы обойти органичения стандарта языка и дыры в его реализациях. Чтобы в результате получить решения, в которых способны разобраться избранные продвинутые C++ники.»
Не надо разбираться в исходниках Буста. Его надо просто качать и использовать так как написано в документации. Или не качать и не использовать. Библиотеки они для того и пишутся, чтобы подключил и начал использовать. Без особого геморроя и плясок с бубном.
«Стоит добавить в проект пару-тройку шаблонных классов и использовать STL, как время компиляции увеличивается чуть ли не на порядок. По сравнению со скоростью компиляции того же D или даже Java скорость компиляции C++ оказывается слишком, слишком медленной.»
Такие проблемы возникают только тогда когда приложение пишется одновременно с фреймворком под это приложение (о фреймворках см. выше). Тогда да компиляция может занимать долгое время. Помнится в свое время кто-то на КРИ рассказывал что у них выделен отдельный сервер под компиляцию всех исходников проекта, который непрерывно маслал эти исходники. Было жестко. Хотя это проблема вобщем-то временная, фреймворк со временем должен устаканиться и его тогда можно запихать в отдельную дллшку и перекомпилировать только при необходимости. Причем такая необходимость будет возникать все реже и реже по мере развития фреймворка.
«Следствием того, что язык C++ никогда не имел большой стандартной библиотеки и при этом развивался в течении длительного времени (имеется в виду добавление в язык шаблонов и исключений) стало наличие целого зоопарка библиотек для выполнения одних и тех же действий. Например, только для GUI можно вспомнить Qt, wxWidgets, FOX Toolkit и Fltk (не считая переодически возникающих молодых конкурентов). Аналогичная картина для работы с XML. Аналогично для системных средств (т.к. многопоточность, файловая система, IPC): ACE, POCO, Boost, Qt.»
Это же хорошо — есть из чего выбрать.
«Все это сопровождается разными подходами к управлению памятью и информированием об ошибках. Так, Qt и FOX Toolkit навязывают разработчику собственную политику использования памяти. POCO выбрасывает исключения для информирования об ошибках, в то время как ACE использует коды возврата и errno»
Про исключения и коды возврата написано выше. Что же касается навязывания чего либо, то такие библиотеки надо сразу жечь на костре, причем вместе с создателями этих библиотек. Оптом так сказать.
По второй ссылке интересного не очень много, видно не умеет автор разоблачительных статей писать. Разоблачает вяло, за накалом идиотии не следит, яростно покровы не срывает. Наоборот вцелом очень спокойно и адекватно объясняет свою позицию. Не то что Боресков, вот тот действительно мастер разоблачений.