Почему программисты на C ++ должны минимизировать использование «нового»?

Поскольку стек быстрый и надежный

В С++ для каждой локальной области видимости в заданной функции требуется только одна команда для выделения пространства - в стеке, и невозможно утечка какой-либо из этой памяти. Этот комментарий предполагал (или должен был предполагать) сказать что-то вроде "использовать стек, а не кучу".

Это сложно.

Во-первых, С++ не собирает мусор. Поэтому для каждого нового должно быть соответствующее удаление. Если вы не введете это удаление, тогда у вас будет утечка памяти. Теперь для простого случая:

std::string *someString = new std::string(...);
//Do stuff
delete someString;

Это просто. Но что произойдет, если "Do stuff" выдает исключение? Упс: утечка памяти. Что произойдет, если "Делать вещи" выдает return раньше? К сожалению, утечка памяти.

И это для простейшего случая. Если вам удастся вернуть эту строку кому-то, теперь они должны ее удалить. И если они передают это в качестве аргумента, должен ли человек, получающий его, удалить его? Когда они должны удалить его?

Или вы можете просто сделать это:

std::string someString(...);
//Do stuff

Нет delete. Объект был создан в "стеке", и он будет уничтожен после того, как он выйдет за рамки. Вы даже можете вернуть объект, передавая его содержимое вызывающей функции. Вы можете передать объект в функции (как правило, в качестве ссылки или const-ссылки: void SomeFunc(std::string &iCanModifyThis, const std::string &iCantModifyThis) и т.д.

Все без new и delete. Там нет вопроса о том, кто владеет памятью или кто несет ответственность за ее удаление. Если вы выполните:

std::string someString(...);
std::string otherString;
otherString = someString;

Понятно, что otherString имеет копию данных someString. Это не указатель; это отдельный объект. У них может быть одно и то же содержимое, но вы можете изменить его, не затрагивая другое:

someString += "More text.";
if(otherString == someString) { /*Will never get here */ }

Посмотрите идею?

Объекты, созданные new, должны быть в конечном итоге delete d, чтобы они не протекали. Деструктор не будет вызван, память не будет освобождена, весь бит. Поскольку С++ не содержит сборку мусора, это проблема.

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

Умные указатели, такие как auto_ptr, shared_ptr, решают проблему с обвисшей ссылкой, но им нужна дисциплина кодирования и есть другие проблемы (копируемость, циклы ссылок и т.д.).

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

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

• С++ не использует менеджер памяти самостоятельно. Другие языки, такие как С#, Java, имеют сборщик мусора для обработки памяти.
• С++ с помощью подпрограмм операционной системы для выделения памяти и слишком много нового/удаления может фрагментировать доступную память
• В любом приложении, если часто используется память, рекомендуется предварительно выделить его и отпустить, когда это не требуется.
• Неправильное управление памятью может привести к утечкам памяти, и это очень сложно отслеживать. Таким образом, использование объектов стека в рамках функции является проверенной техникой.
• Недостатком использования объектов стека является создание нескольких копий объектов при возврате, передача функций и т.д. Однако интеллектуальные компиляторы хорошо знают об этих ситуациях, и они хорошо оптимизированы для производительности
• Это действительно утомительно в С++, если память выделяется и выпускается в двух разных местах. Ответственность за выпуск всегда является вопросом, и в основном мы полагаемся на некоторые общедоступные указатели, объекты стека (максимально возможные) и такие методы, как auto_ptr (объекты RAII)
• Лучше всего, что вы контролируете память, а самое худшее - у вас не будет никакого контроля над памятью, если мы будем использовать неправильное управление памятью для приложения. Аварии, вызванные повреждением памяти, являются самыми отвратительными и трудными для отслеживания.

Я вижу, что несколько важных причин для того, чтобы сделать как можно меньше новых, пропущены:

Оператор new имеет недетерминированное время выполнения

Вызов new может или не может заставить ОС выделять новую физическую страницу для вашего процесса, это может быть довольно медленным, если вы часто это делаете. Или у этого уже может быть подходящее место памяти, мы не знаем. Если ваша программа должна иметь согласованное и прогнозируемое время выполнения (например, в режиме реального времени или в игре/физическом моделировании), вам нужно избегать new в ваших критических циклах времени.

Оператор new - это неявная синхронизация потоков

Да, вы меня слышали, ваша ОС должна убедиться, что ваши таблицы страниц согласованы, и поскольку такой вызов new приведет к тому, что ваш поток получит неявный блокировку мьютекса. Если вы последовательно вызываете new из многих потоков, вы фактически сериализуете свои потоки (я сделал это с 32 процессорами, каждый из которых попадал на new, чтобы получить несколько сотен байт каждый, ох! Это была королевская лаваша для отладки )

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

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

Самый простой способ сделать это - создать объект в автоматическом хранилище, поэтому С++ знает, как его уничтожить, когда он выходит из области видимости:

 {
    File foo = File("foo.dat");

    // do things

 }

Теперь заметите, что, когда вы отвалитесь от этого блока после конечной скобки, foo выходит за рамки. С++ вызовет его dtor автоматически для вас. В отличие от Java, вам не нужно ждать, пока GC ее не найдет.

Если бы вы написали

 {
     File * foo = new File("foo.dat");

вы хотите явно сопоставить его с

     delete foo;
  }

или даже лучше, выделите File * как "умный указатель". Если вы не будете осторожны, это может привести к утечкам.

Сам ответ ошибочно полагает, что если вы не используете new, вы не выделяете кучу; на самом деле, на С++ вы этого не знаете. В лучшем случае вы знаете, что небольшое количество памяти, скажем, одного указателя, конечно же выделяется в стеке. Однако рассмотрим, является ли реализация файла чем-то вроде

  class File {
    private:
      FileImpl * fd;
    public:
      File(String fn){ fd = new FileImpl(fn);}

то FileImpl по-прежнему будет выделено в стеке.

И да, вы должны быть уверены, что

     ~File(){ delete fd ; }

в классе; без него вы будете утечка памяти из кучи, даже если вы явно не выделили кучу вообще.

Pre-С++ 17:

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

Рассмотрим "осторожного" пользователя, который не забывает оборачивать объекты в умные указатели:

foo(shared_ptr<T1>(new T1()), shared_ptr<T2>(new T2()));

Этот код опасен, потому что нет никакой гарантии, что shared_ptr до T1 или T2. Следовательно, если один из new T1() или new T2() завершится неудачно после того, как другой преуспеет, то первый объект будет пропущен, потому что не существует shared_ptr для его уничтожения и освобождения.

Решение: используйте make_shared.

Post-С++ 17:

Это больше не проблема: С++ 17 налагает ограничение на порядок этих операций, в этом случае гарантируя, что за каждым вызовом new() должен немедленно следовать построение соответствующего умного указателя, без других операций в между. Это подразумевает, что ко времени вызова второго new() гарантируется, что первый объект уже обернут в его умный указатель, таким образом предотвращая любые утечки в случае возникновения исключения.

Более подробное объяснение нового порядка оценки, введенного С++ 17, было предоставлено Барри в другом ответе.

Спасибо @Remy Lebeau за то, что он указал, что это все еще проблема в С++ 17 (хотя и не так): конструктор shared_ptr может не выделить свой управляющий блок и выполнить throw, и в этом случае переданный ему указатель не удаляется.

Решение: используйте make_shared.

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

Распределение объектов в стеке, опираясь на их неявное разрушение, является простой моделью. Если требуемая область действия объекта подходит для этой модели, тогда нет необходимости использовать new(), с привязкой delete() и проверкой указателей NULL. В случае, когда у вас есть много недолговечных объектов, выделение в стеке должно уменьшить проблемы фрагментации кучи.

Однако, если время жизни вашего объекта должно превышать текущую область, то new() - правильный ответ. Просто убедитесь, что вы обращаете внимание на то, когда и как вы называете delete(), и возможности указателей NULL, используя удаленные объекты и все другие ошибки, которые идут с использованием указателей.

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

Class var;

он помещается в стек.

Вам всегда нужно вызвать destroy на объект, который вы разместили в куче, с новым. Это открывает возможности утечки памяти. Объекты, помещенные в стек, не подвержены утечке памяти!

Одна из важных причин избежать чрезмерного использования кучи для производительности - это, в частности, использование механизма управления памятью по умолчанию, используемого С++. Хотя распределение может быть довольно быстрым в тривиальном случае, выполнение большого количества new и delete на объектах неравномерного размера без строгого порядка приводит не только к фрагментации памяти, но также усложняет алгоритм распределения и может полностью уничтожить производительность в определенных случаях.

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

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

Я склонен не соглашаться с идеей использования нового "слишком много". Хотя использование оригинального плаката нового с системными классами немного смешно. (int *i; i = new int[9999];? действительно? int i[9999]; намного яснее.) Я думаю, что это то, что получало кокер-комментатор.

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

Однако, когда вы работаете со своими собственными классами/объектами (например, исходный класс Line poster), вы должны начать думать о проблемах, таких как объем памяти, постоянство данных и т.д. самостоятельно. На данный момент использование нескольких ссылок на одно и то же значение неоценимо - оно позволяет создавать такие конструкции, как связанные списки, словари и графики, где несколько переменных должны иметь не только одно и то же значение, но и ссылаться на один и тот же объект в памяти. Однако класс Line не имеет ни одного из этих требований. Таким образом, исходный код плаката на самом деле абсолютно не нужен для new.

Я думаю, что плакат означал You do not have to allocate everything on the heap, а не stack.

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

Две причины:

• В этом случае это не нужно. Вы делаете свой код ненужным более сложным.
• Он выделяет пространство в куче, и это означает, что вы должны помнить delete позже, иначе это приведет к утечке памяти.

Еще одно замечание ко всем приведенным выше правильным ответам, это зависит от того, какое программирование вы делаете. Например, разработка ядра в Windows → Стек сильно ограничен, и вы не сможете воспринимать ошибки страницы, как в режиме пользователя.

В таких средах новые или C-подобные вызовы API предпочтительны и даже необходимы.

Конечно, это всего лишь исключение из правил.

new есть новый goto.

Напомним, почему goto настолько оскорблен: хотя он является мощным инструментом низкого уровня для управления потоком, люди часто использовали его излишне сложными способами, из-за которых сложный код не выполнялся. Более того, наиболее полезные и простые для чтения шаблоны были закодированы в структурированных операциях программирования (например, for или в while); конечный эффект заключается в том, что код, где goto является подходящим способом, довольно редок, если у вас возникает соблазн написать goto, вы, вероятно, делаете что-то плохо (если вы действительно не знаете, что делаете).

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

Я бы даже утверждал, что new хуже, чем goto, из-за необходимости соединять new и delete утверждения.

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

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

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

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

Традиционные шаблоны проектирования, особенно те, о которых говорится в GoF, используйте new много, так как они являются типичным кодом OO.

new выделяет объекты в куче. В противном случае объекты выделяются в стеке. Посмотрите разницу между двумя.