C++: Используете ли вы Loki или Boost для функторов?

Question

Я читал книгу Александреску, современный дизайн на C++, и меня очень впечатлили методы, которые он использует, поэтому я хотел добавить Loki library в свое приложение.

Однако после дальнейшего расследования, я увидел, что импульс, который я уже использую, дает много подобной функциональности (не все, хотя, я не мог найти одиночки в импульс, например)

I в основном интересовался использованием loki из-за разработки на основе политики и функторов.

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

Прежде чем выбрать использование boost или loki для функторов и политик, я хотел бы узнать мнение людей, которые используют их в реальной жизни.

Иногда вещи выглядят очень хорошо на бумаге, но имеют некоторые недостатки при использовании их для реального :)

Answer 1

Я использую Boost во всей своей среде C++ как расширение стандартной библиотеки (с VC9 и VC10).

Я не использую его во всех проектах.

Я использую его для личных проектов (в основном игр), где я получил полный контроль над зависимостями.

Я использую boost :: function в большом игровом проекте (с несколькими другими библиотеками от boost).

Локи тоже хорош, но я не чувствовал необходимости. Я думаю, что единственная часть библиотеки, которую я собираюсь использовать, - это Синглтон, но я использую обычную, которая на данный момент достаточно хороша.

Answer 2

C++ 0x является то, что я использую для быстрого функциональных объектов.

Answer 3

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

Answer 4

У Alexandrescu были очень интересные идеи (списки типов, шаблоны классов на основе политик и т. Д.), Но многие из них были улучшены в процессе повышения и были протестированы в более широком диапазоне компиляторов для мобильности и правильности.

Я бы порекомендовал предпочитать повышение по возможности только по этим причинам. Тем не менее, Modern C++ Design по-прежнему обеспечивает много понимания гибкости C++ и взгляда на ум одного человека (очень хороший), чтобы подходить к множеству общих проблем программирования.

Например, на основе политик смарт-указатели очень аккуратная идея, но мы можем найти, почему авторы решили не Повышение реализовать shared_ptr и scoped_ptr таким образом:

А. Параметризация отпугивает пользователь. Шаблон shared_ptr тщательно создан для удовлетворения общих потребностей без обширной параметризации.В какой-то день будет изобретен умный указатель с высокой степенью конфигурирования, который может быть использован, а также очень легко использовать и очень трудно использовать. До тогда shared_ptr является умным указателем выбора для широкого спектра приложений . (Те, кто заинтересован в политики на основе смарт-указатели должны чтения Modern C++ Design Андрей Alexandrescu.)

Если вам не нужно большое разнообразие интеллектуальных указателей и вы и ваша команда комфортно работать экстенсивно с шаблоном параметризации, тогда политический подход к внедрению интеллектуальных указателей может сработать для вас. Однако scoped_ptr и shared_ptr (вместе со слабым_ptr) имеют тенденцию делать работу достаточно тщательно. Комбинаторное поведение классов политики, вероятно, лучше используется для чего-то, для которого существует множество разнообразных полезных комбинаций.

Тем не менее, есть еще интересные предложения Александреску о том, что повышение не затронуло. Например, MOJO по-прежнему полезен до тех пор, пока компиляторы не выполняют лучшую работу по реализации конструкторов перемещения или пока мы не сможем использовать ссылки rvalue из C++ 0x. У него также есть очень интересные мысли о реализации распределителей памяти.

Что касается вопроса, мы используем части Loki, необходимые для mojo в нашем коммерческом проекте, но в основном повышаем, когда это уместно.