Продуктивность программиста с STL против пользовательских классов утилит

Question

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

Существуют ли какие-либо исследования, которые пытаются количественно оценить или даже намекают на повышение производительности от использования STL?

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

Answer 1

Нет исследований, которые показали бы, что STL более продуктивен только потому, что это STL. Повышение производительности благодаря его использованию объясняется тем, что стандартные программисты знакомы с ним, а также тем, что код уже написан и протестирован.

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

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

Возможно, вы также захотите расширить использование STL, чтобы каждый мог сохранить свои навыки в C ++. Хотя я бы не отказался от кандидата на C ++, который не знал STL, я бы определенно рассматривал его как черную метку.

Answer 2

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

STL будет более продуктивным для новых разработчиков в вашем магазине, потому что, скорее всего, они уже знакомы с ним. Ваши пользовательские библиотеки будут чужими и, вероятно, будут лишены функций, которые разработчики привыкли использовать. Это не большая проблема после начального периода наращивания для новых разработчиков.

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

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

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

Answer 3

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

Иногда вы можете помочь преодолеть разрыв между двумя мирами, переоборудовав итераторы в стиле STL в ваши старые классы, хотя будьте осторожны, чтобы сделать их правильными!

Answer 4

Единственный аргумент в пользу повышения производительности с помощью STL, о котором я могу подумать, - это возможность легкой интеграции других библиотек - Boost, Arabica, SOCI и т. Д. Все они предназначены для работы с STL, а не с вашими внутренними классами контейнеров.

Answer 5

Я думаю, что критическим фактором является уровень текучести команды разработчиков.

Если команда стабильна и работает над этим кодом в течение десяти лет и, вероятно, через десять лет, они будут более продуктивными, используя знакомые им служебные классы, и подталкивают их к использованию STL приведет к снижению производительности и ошибок.

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

Answer 6

Причины, которые я вижу:

Качество кода

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

Их задача - создать пригодный для использования STL, что означает, что каждая функция / метод / объект в любом случае подвергается тщательному тестированию.

ремонтопригодность кода

С оборотом некоторый код может медленно и незаметно остаться без поддержки. Это означает, что если в этом коде есть ошибка или если ее производительность или интерфейс отсутствуют (см. «Качество» выше), то вы не найдете никого, кто мог бы ее профессионально улучшить.

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

И я даже не упоминаю синдром «Я никогда не коснусь этого слизистого кода», когда кто-то пытается исправить код, просто обнаруживает, что не понимает, почему это было сделано таким образом (из-за макросов, странных условия и т.д ..

Заключение

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

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

Answer 7

Одно из мест, где STL полезен, не в реальных библиотеках и т. Д., Которые предоставляет STL, а в стиле кодирования, который использует STL.

Далее необходимо 2 основных теста:

struct DoSomething {
  bool operator ()(Container::value_type const & v) const
  {
    // ...
  }
};

void bar (Container const & c)
{
  std::for_each (c.begin (), c.end (), DoSomething ());
}

Первые тесты подтверждают, что DoSomething :: operator () делает то, что должен. Второй тест должен только проверить, что DoSomething :: operator () вызван.

Это разделение может помочь повысить производительность по сравнению с рукописным циклом. Для вышеперечисленного количество тестов является суммой «что нужно сделать» и тестов, которые выполняются для непустого контейнера. В случае цикла for количество тестов является продуктом тестов.

Answer 8

Может случиться так, что обратное верно, если домашние утилиты каким-либо образом зависят от конкретной работы, которую вы делаете.

Answer 9

Я не думаю, что есть способ оправдать замену этих пользовательских классов оптом, к сожалению. Если возможно, замените их на компоненты STL, класс в то время.

Это проблема технического обслуживания и читабельности. (1) Использование STL помогает сопровождающим понять код с первого взгляда, в отличие от необходимости изучать собственные реализации. (2) STL ХОРОШО документирован и хорошо понят - как насчет ваших пользовательских классов? (3) STL хорошо проверен. (4) STL имеет асимптотические верхние и нижние границы времени выполнения.

Удачи.

Answer 10

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