Повышение адвокатуры - необходимая помощь

Question

Возможных дубликаты
Is there a reason to not use Boost?
What are the advantages of using the C++ BOOST libraries?

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

я повадился размещение следующей цитаты из TR1 smart pointer proposal:

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

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

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

Answer 2

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

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

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

Answer 3

Я должен был поддерживать компонент, используя эти старые марочные Tools.h ++ от Roguewave, в системе Solaris.

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Стоимость подталкивания проекта (http://www.boost.org/development/index.html)

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