Когда следует использовать алгоритмы STL вместо собственных?

Question

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

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

Я никогда не видел код C ++, который использует алгоритмы STL.От примера кода в статьях веб-страницы до проектов с открытым исходным кодом, я не видел их использования.

Они используются чаще, чем кажется?

Answer 1

Краткий ответ: Всегда.

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

Отредактировано, чтобы добавить: (Хорошо, не очень действительно всегда, но если вам нужно спросить, следует ли вам использовать STL, ответ «да».)

Answer 2

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

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

Это действительно так просто. В некоторых случаях то, что вы делаете, требует тайного вызова с использованием std::bind1st и std::mem_fun_ref (или что-то в этом порядке), которое является чрезвычайно плотным и непрозрачным, где цикл for будет почти тривиально простым и простым. В таком случае, продолжайте и используйте цикл for.

Если не существует стандартного алгоритма, который делает то, что вы хотите, позаботьтесь и посмотрите снова - вы часто упускаете то, что действительно будет делать то, что вы хотите (одно место, которое часто упускается: алгоритмы в <numeric> часто полезны для нечислового использования). Посмотрев пару раз и подтвердив, что на самом деле не является стандартным алгоритмом, чтобы делать то, что вы хотите, вместо того, чтобы писать этот цикл for (или что-то еще), подумайте о написании универсального алгоритма, чтобы тебе нужно сделать. Если вы используете его в одном месте, есть большая вероятность, что вы можете использовать его еще два или три, и в этот момент это может быть большой победой в ясности.

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

Answer 3

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

Answer 4

Когда следует использовать алгоритмы STL вместо собственных?

Когда вы цените свое время и здравомыслие и у вас есть более забавные вещи, чем изобретать велосипед снова и снова.

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

Answer 5

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

Answer 6

Есть много хороших алгоритмов, помимо таких вещей, как std::foreach.

Однако есть много нетривиальных и очень полезных алгоритмов:

• Сортировка: std::sort, std::upper_bound, std::lower_bound, std::binary_search
• Мин. / Макс. std::max, std::min, std::partition, std::min_element, std::max_element
• Искать как std::find,std::find_first_of и т. Д.

и многие другие.

Алгоритмы, такие как std::transform, очень полезны для лямбда-выражений C ++ 0x или тому подобного boost::lambda или boost::bind

Answer 7

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

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

-

Причины, по которым вы можете не видеть его в коде, заключаются в том, что он является либо устаревшим кодом, либо написанным устаревшими программистами. У нас было около 20 лет программирования на C ++ до появления STL, и на тот момент у нас было сообщество программистов, которые знали, как делать вещи по-старому, и еще не изучали путь STL. Это, вероятно, останется на поколение.

Answer 8

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

Последние 6 лет я интенсивно использую STL и хотя я пытался использовать алгоритмы STL везде, где мог, в большинстве случаев это делало мой код более неясным, поэтому я вернулся к простому циклу. Теперь с C ++ 0x наоборот, код, кажется, всегда выглядит проще с ними.

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

Answer 9

Имейте в виду, что алгоритмы STL охватывают множество основ, но большинство разработчиков на C ++, вероятно, в конечном итоге закодируют что-то, что эквивалентно std::find(), std::find_if() и std::max() почти каждый день их трудовой жизни ( если они не используют версии STL уже). Используя версии STL, вы отделяете алгоритм как от логического потока вашего кода, так и от представления данных .

Для других менее часто используемых алгоритмов STL, таких как std::merge() или std::lower_bound(), это чрезвычайно полезные процедуры (первая - для объединения двух отсортированных контейнеров, вторая - для определения, куда вставить элемент в контейнер, чтобы сохранить его порядок. ). Если бы вы попытались реализовать их самостоятельно, то, вероятно, потребовалось бы несколько попыток (алгоритмы не сложны, но вы, вероятно, получили бы ошибки по одному или тому подобное).

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

Answer 10

Единственный раз, когда я не использую алгоритмы STL, это когда различия между кросс-платформенными реализациями влияют на результат моей программы.Это произошло только в одном или двух редких случаях (на Playstation 3).Хотя интерфейс STL стандартизирован для разных платформ, реализация не является.

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

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