К STL или! STL, который является [закрытым] вопросом

Я взвешиваю этот очень популярный вопрос, потому что никто не написал версию с тасованием. Стиль сильно заимствован из Arrays.java, потому что в настоящее время не разграбляет технологию Java? Включены общие и int реализации.

   /**
    * Shuffles elements from {@code original} into a newly created array.
    *
    * @param original the original array
    * @return the new, shuffled array
    * @throws NullPointerException if {@code original == null}
    */
   @SuppressWarnings("unchecked")
   public static <T> T[] shuffledCopy(T[] original) {
      int originalLength = original.length; // For exception priority compatibility.
      Random random = new Random();
      T[] result = (T[]) Array.newInstance(original.getClass().getComponentType(), originalLength);

      for (int i = 0; i < originalLength; i++) {
         int j = random.nextInt(i+1);
         result[i] = result[j];
         result[j] = original[i];
      }

      return result;
   }


   /**
    * Shuffles elements from {@code original} into a newly created array.
    *
    * @param original the original array
    * @return the new, shuffled array
    * @throws NullPointerException if {@code original == null}
    */
   public static int[] shuffledCopy(int[] original) {
      int originalLength = original.length;
      Random random = new Random();
      int[] result = new int[originalLength];

      for (int i = 0; i < originalLength; i++) {
         int j = random.nextInt(i+1);
         result[i] = result[j];
         result[j] = original[i];
      }

      return result;
   }
40
задан Judah Gabriel Himango 7 October 2008 в 01:22
поделиться

12 ответов

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

можно также выбрать not to use STL for a particular case, потому что более применимые контейнеры существуют, которые не находятся в текущем стандарте, таком как повышение:: массив или повышение:: unordered_map.

31
ответ дан 23 September 2019 в 15:59
поделиться

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

2
ответ дан Jamie Eisenhart 23 September 2019 в 15:59
поделиться

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

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

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

2
ответ дан Ferruccio 23 September 2019 в 15:59
поделиться

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

3
ответ дан Caleb Huitt - cjhuitt 23 September 2019 в 15:59
поделиться

Кодирование для Symbian.

STLPort действительно поддерживает Symbian 9, таким образом, дело против использования STL более слабо, чем это раньше было ("это не доступно", довольно убедительный случай), но STL все еще чужд всем библиотекам Symbian, так может быть больше проблемы, чем просто выполнение вещей Symbian путь.

, Конечно, это могло бы быть обсуждено на этих основаниях, что кодирование для Symbian не является "проектом программирования на C++".

5
ответ дан Steve Jessop 23 September 2019 в 15:59
поделиться

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

6
ответ дан coppro 23 September 2019 в 15:59
поделиться

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

15
ответ дан Evan Teran 23 September 2019 в 15:59
поделиться

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

  1. Новая способность программистов понять контейнеры со дня одно предоставление им больше времени для изучения другого кода в проекте. (принятие, они уже знают STL как любой компетентный программист на C++, было бы)
  2. , Исправляющие ошибки в контейнерах сосут и напрасно тратят время, который мог быть потрачен, улучшив бизнес-логику.
  3. Наиболее вероятный Вы не собираетесь писать им, а также STL реализован так или иначе.

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

26
ответ дан Matt Price 23 September 2019 в 15:59
поделиться

Главные причины не использовать STL состоят в том что:

  1. Ваша реализация C++ стара и имеет ужасную шаблонную поддержку.
  2. Вы не можете использовать динамическое выделение памяти.

Оба - очень редкие требования на практике.

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

47
ответ дан Greg Rogers 23 September 2019 в 15:59
поделиться

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

6
ответ дан Trent 23 September 2019 в 15:59
поделиться

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

4
ответ дан Nemanja Trifunovic 23 September 2019 в 15:59
поделиться

Я запустил, программирование C въезжают задним ходом приблизительно приблизительно 1984 и никогда не использовали STL. За эти годы я прокрутил свои собственные функциональные библиотеки, и они развились и выросли, когда STL еще не был стабилен и или испытал недостаток в кросс-платформенной поддержке. Моя общая библиотека выросла для включения кода другими (главным образом вещи как libjpeg, libpng, ffmpeg, mysql) и немногие другие, и я сохранил бы сумму внешнего кода в нем к минимуму. Я уверен теперь, что STL является большим, но откровенно я доволен объектами на своей панели инструментов и не вижу потребности в этой точке для загрузки его большим количеством инструментов. Но я, конечно, вижу великое стремительно, что новые программисты могут сделать при помощи STL, не имея необходимость кодировать все это с нуля.

1
ответ дан KPexEA 23 September 2019 в 15:59
поделиться
Другие вопросы по тегам:

Похожие вопросы: