немного о кроссплатформенности и библиотеках
Решил вот поделиться своим мнением насчет известных библиотек для кроссплатформенной разработки на С++.
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 год на дворе уже заканчивается. Уже давно пора делить интерфейс и реализацию. Нахера клиенту класса знать о кишках (пусть даже и в приватной части) и тянуть за собой многокилометровое говно в виде огромного списка инклюдов для всех этих кишков?
Если у кого какие вопросы- с радостью отвечу:)
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 год на дворе уже заканчивается. Уже давно пора делить интерфейс и реализацию. Нахера клиенту класса знать о кишках (пусть даже и в приватной части) и тянуть за собой многокилометровое говно в виде огромного списка инклюдов для всех этих кишков?
Если у кого какие вопросы- с радостью отвечу:)