vitamin_caig (vitamin_caig) wrote,
vitamin_caig
vitamin_caig

Categories:

немного о кроссплатформенности и библиотеках

Решил вот поделиться своим мнением насчет известных библиотек для кроссплатформенной разработки на С++.

boost. Всем известный набор велосипедов. Без кавычек, потому что в хорошем смысле- позволяет заюзать готовые решения и не писать свои. С какими частями пришлось столкнуться:
- boost.thread. Многопоточность как она есть. Создание потоков, причем без приплясывания со статической функцией и передачей this через void*. Плюс всякие там условные переменные, мьютексы (разных видов, половину не разобрал), барьеры.
- boost.smart_ptr. Расширенная реализация "умных" указателей. Мега-вещь. При правильном подходе позволяет не заботиться об управлении памятью. Также не нужно забывать про boost::make_shared.
- boost.bind/boost.function/boost.member_function/boost.ref/boost.type_traits. Продвинутое расширение стандартных инструментов для мета- и функционального программирования. Требует ответственности, ибо неоправданно использование загромождает и усложняет код.
- boost.array. Простой враппер для массивов константного размера. Позволяет удалить это знание о константности из обрабатывающего кода. Полезна вещь.
- boost.crc. Подсчет разного рода контрольных сумм. Тут и сказать нечего.
- boost.format. Выход для тех, кто выяснил наконец-таки, что printf - это ужасно, плохо и опасно, а std::ostream- правильно, но неудобно.
- boost.optional. Когда нужно не просто хранить переменную, но и сам факт ее наличия/инициализирования.
- boost.program_options. Реализация велосипеда, который, хоть раз, но писали все: парсинг параметров командной строки. С лету разобраться проблематично, но с помощью примеров вполне можно. Не работает с широкими символами, иногда глючит на высоких режимах оптимизации компилятора (из-за хаков внутри), но использовать можно и нужно.
- boost.string_algo. Реализация алгоритмов работы со строками, являющихся классическим источником велосипедизма.
- boost.tuple. Для тех, кто любит использовать std::pair, но сожалеет о ее нерасширяемости.
- boost.variant. Исключающее хранение нескольких типов в одной переменной. В некоторых ситуациях может быть полезно.
- boost.static_assert. Проверки утверждений на этапе компиляции. Наравне с классическими утверждениями (assertions), можно использовать для фиксации предположений и прочего. Чтоб при изменениях не торчать в отладчике.
Сталкивался, но не использовал в продуктах:
- boost.regex. Регулярные выражения. Вспоминается шутка: "если у вас есть проблема и вы собираетесь решить ее с помощью регулярных выражений, у вас есть две проблемы".
- boost.xpressive. Те же регулярки, но в синтаксисе языка и задаваемые статически на этапе компиляции. К сожалению, не все компиляторы могут пережевать более-менее сложное выражение на нем (MSVS7.1 падает с переполнением мангленного имени переменной).
- boost.call_traits. Тоже часть из метапрограммирования. Автоматически детектит наилучший способ передачи параметра в функцию (по значению/по ссылке). Загромождение прототипов- плата за использование. Для библиотек- очень полезно, ценность в продуктовом коде- крайне ограниченная (как и метапрограммирования вообще)


QT. Монстр. Тоже в хорошем смысле. Можно писать приложения любой ориентированности (даже без пользовательского интерфейса, как это ни странно).
Плюсы для меня:
+ превосходная документированность. Справочник как в онлайне, так и в оффлайне. Хотя примеры некоторых аспектов не блещут широтой, достаточны для разбирательства.
+ оно действительно работает на разных платформах:) Конечно, это не даром, в код страшно глянуть- сплошь сборище говнокода, костылей и подпорок. Но меня, как пользователя, это не волнует.
+ оно даже работает на встроенных системах (например, dingux). Разумеется, своя специфика, но перестраивать сознание не надо.
Минусы:
- нетривиальный процесс строительства кода. Поскольку я не использую qmake, все приседания с вызовом метакомпилятора, компилятора ресурсов и пользовательского интерфейса надо реализовывать самостоятельно.
- сигнал-слот система перекладывает ответственность за правильность связывания с compile-time на run-time. Что чревато проблемами в непокрытых запуском участках кода.
- собственная система управления памятью. Эдакий недо-GC. Не всегда очевидно кто и когда должен удалять объекты, что чревато утечками памяти.
- в дополнение к предыдущему пункту- собственные утечки памяти, с которыми ничего не поделаешь.
- ужасный стиль примеров в документации и учебниках (положа руку на сердце- этим страдает 99% книг про С++). Йоу! Чуваки! 2010 год на дворе уже заканчивается. Уже давно пора делить интерфейс и реализацию. Нахера клиенту класса знать о кишках (пусть даже и в приватной части) и тянуть за собой многокилометровое говно в виде огромного списка инклюдов для всех этих кишков?

Если у кого какие вопросы- с радостью отвечу:)
Tags: c++, программирование
Subscribe

  • Android

    Неожиданно обнаружил, что больше года не писал сюда. Как-то не тянуло:) Кому не интересны всякие там технические детали, могут не читать. В…

  • немного о проектировании интерфейсов

    Давно уже ничего не писал, а тут зуд в известном месте заставляет немного размять мозги и занять их тем, для чего они (мои мозги) предназначены-…

  • PR for software

    Ох, нелегкая это работа продвигать свой софт в массы. Даже если этот софт бесплатный и единственное, что требуется от пользователя- сообщать о багах…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments