Усилить адвокацию - нужна помощь

Question

Возможные дубликаты
Есть ли причина не использовать Boost?
В чем преимущества использования библиотек C ++ BOOST?

Хорошо, вопрос высокого уровня: «Пожалуйста, предоставьте мне то, что вы считаете наиболее эффективными аргументами того, почему весь Boost или некоторые его отдельные части должны быть скомпилированы в системе нашей компании и одобрены в стандартах разработки программного обеспечения ».

Детали того, что мне нужно:

• С удовольствием примет как положительные аргументы (зачем устанавливать), так и предложенные опровержения вероятных контраргументов, которые я мог бы услышать (см. Контекст вопроса ниже).

• Аргументы должны быть направлены как на членов технической группы разработки программного обеспечения, так и / или очень старших технических руководителей - иными словами, для последних детали аргумента могут / должны быть техническими , но суть аргумента должна заключаться в том, «как бы это заработало / сэкономило компании X денег против потери компании Y денег как стоимости их добавления в наш набор инструментов».

Контекст вопроса:

• Я разработчик в компании с несколькими сотнями разработчиков, многие из которых делают C ++.

• Мне посчастливилось переназначить меня с моего любимого места разработки на Perl в команду, где я также занимаюсь разработкой на C ++. До сих пор я нашел множество вещей, которые я мог бы легко сделать в Perl, которые очень трудно / громоздко сделать в C ++ (цикл foreach в качестве примера), и каждый раз, когда я нажимаю на одну из них, ответ на 50%, скорее всего, будет «Вы не может сделать это в стандартном C ++, но вы можете сделать это с помощью Boost "

• Наш инструментарий включает в себя несколько устаревших библиотек RogeWave и ОЧЕНЬ ограниченное количество библиотек Boost (например, без регулярных выражений, без foreach) очень старых сборок.

• Любая разработка должна использовать библиотеки, скомпилированные и проверенные командой разработчиков программного обеспечения. Это жесткое и быстрое правило.

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

Итак, я ищу примеры того, какие части Boost настолько замечательны (с точными оценками затрат / выгод), что их установка была бы очевидным усилием для разработки программного обеспечения.

Заранее спасибо за любые идеи / предложения / примеры.

Пожалуйста, не отмечайте этот вопрос как субъективный, так как я ищу измеримые ответы, а не просто чудесные чувства:)

Answer 1

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

У меня появилась привычка публиковать следующую цитату из предложения интеллектуального указателя TR1 :

Разработчики Boost обнаружили, что умный указатель совместного владения чрезвычайно труден для правильной реализации. Другие сделали то же самое наблюдение. Например, Скотт Мейерс [Meyers01] говорит:

"Сам STL не содержит интеллектуального указателя для подсчета ссылок, и написание хорошего - того, который работает правильно все время - достаточно сложно, так что вы не захотите это делать, если не будете обязаны. Я опубликовал код для интеллектуального указателя с подсчетом ссылок в More Effective C ++ в 1996 году, и, несмотря на то, что он базировался на устоявшихся реализациях интеллектуальных указателей и подвергался тщательному предварительному обзору, подготовленному опытными разработчиками, в течение многих лет накапливался небольшой список действительных отчетов об ошибках. замечательно количество хитрых способов, с помощью которых умные указатели подсчета ссылок могут потерпеть неудачу. "

Этот плюс подробный анализ ошибок, которые я обнаружил, обычно давал мне работу по включению библиотек надстроек в базу кода. :)

Answer 2

Мне кажется, вы делаете это неправильно. Поскольку предложения о добавлении новых библиотек встретят большое сопротивление, даже не пытайтесь спорить о повышении в целом . Вместо этого выбирайте свои битвы.

Найдите конкретные библиотеки Boost, которые вы знаете (с вашим знанием приложения, в котором оно будет использоваться) будут полезны и сэкономят время и деньги. А затем предложите добавить их.

Я мог бы легко перечислить Boost libs, которые я нашел полезными, и почему я считаю, что они великолепны, но я не знаю, будут ли они любого использования в вашем приложении.

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

Answer 3

1. Это открытый стандарт, не контролируемый конкретной компанией (без затрат на лицензирование)
2. Это кроссплатформенная
3. Это профессионально разработано / написано и очень быстро / эффективно проверено
4. Существуют реализации с открытым исходным кодом, которые ваша команда может скомпилировать самостоятельно.
5. Boost скоро станет частью стандарта C ++ STL

Вот немного устаревшая статья 2005 года о докторе Доббсе, в которой обсуждается грядущий стандарт C ++ 0x.

http://www.ddj.com/cpp/184401958

Answer 4

Boost - отличный инструмент и неоценимая часть разработки нашего продукта (мы бы потеряли без smart_ptr) ... но поскольку он меняется так быстро, стабильность релизов может быть достигнута.

Например, мы с радостью представили новые версии Boost, как только они появились, не задумываясь. Так продолжалось до тех пор, пока мы не были поражены ошибкой в ​​библиотеке потоков 1.35, которая приводила к случайным (то есть трудным для отладки), но критическим ошибкам. К счастью, мы определили проблему до того, как что-либо было опубликовано, и смогли вернуться к 1.34.

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

Answer 5

Мне пришлось поддерживать компонент, используя тот старый винтажный Tools.h ++ из Roguewave, в системе Solaris.

В Solaris, если мы хотим использовать boost, нам нужно использовать либо gcc, либо SunStudio с реализацией стандарта STLport (вместо Roguewave one). И поскольку для Tools.h ++ требуется старая стандартная реализация Roguewave - в Solaris - мне пришлось отказаться от наддува.

В конце я переписал упрощенную версию нескольких нужных мне форсированных функций.

Если вы окажетесь в той же ситуации (*), вы не сможете перейти из библиотеки Roguewave, чтобы легко ее повысить. Эта операция сопряжена с незначительными затратами, поскольку, например, контейнеры-указатели из обеих библиотек имеют совершенно разные интерфейсы.

(*) Там, где мы не можем медленно менять биты за битами старого кода, чтобы постепенно использовать boost. В этой ситуации миграция должна быть радикальной и одновременно менять каждое появление Tools.h ++ на что-то более модное или даже лучшее.

NB. Большинство людей могут постепенно использовать надстройку в старых проектах и ​​могут упустить очень важный, и да, технический момент. Отсюда мой отрицательный ответ.

Answer 6

Вот два предложения для поддержки повышения:

Кто использует повышение? (http://www.boost.org/users/uses.html)

во многих крупных проектах используется boost: (например, Adobe Photoshop, CERN)

Повышение стоимости проекта (http://www.boost.org/development/index.html)

Сколько бы стоило нанять команду, чтобы написать повышение с нуля? Там есть изящный (несколько бесполезный) калькулятор, который помогает представить его в перспективе.