Управление памятью C++

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

Я добавил бы другое правило здесь:

• Не делайте новый/удаляющий объект, когда автоматический объект сделает очень хорошо.

Мы нашли, что программисты, которые плохо знакомы с C++ или программистами, происходящими законченный из языков как Java, кажется, узнают о новом и затем одержимо используют его каждый раз, когда они хотят создать любой объект, независимо от контекста. Это особенно пагубно, когда объект создается локально в функции просто, чтобы сделать что-то полезное. Используя новый таким образом может быть вредно для производительности и может сделать слишком легким представить глупые утечки памяти, когда соответствие удаляет, забыт. Да, интеллектуальные указатели могут помочь с последним, но это не решит проблемы производительности (предполагающий, что новый/удаляющий или эквивалент используется негласно). Интересно (хорошо, возможно), мы нашли, что удаляют, часто имеет тенденцию быть более дорогим, чем новый при использовании Visual C++.

Часть этого беспорядка также прибывает из факта, который функционирует, они звонят, мог бы взять указатели или даже интеллектуальные указатели, как аргументы (когда ссылки, возможно, будут лучшими/более ясными). Это заставляет их думать, что они должны "создать" указатель (много людей, кажется, думает, что это - то, что новый делает) смочь передать указатель на функцию. Очевидно, это требует некоторых правил о том, как API записаны для создания соглашений о вызовах максимально однозначными, которые укреплены с четкими комментариями, предоставленными прототипом функции.

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

Иногда необходимо выделить объекты динамично, но они будут только использоваться в определенном промежутке времени. Например, в предыдущем проекте я должен был создать сложное представление в оперативной памяти схемы базы данных - в основном сложный циклический график объектов. Однако график был только необходим на время соединения с базой данных, после которого все узлы могли быть освобождены в одном выстреле. В этом виде сценария хороший шаблон для использования является чем-то, что я называю "локальной идиомой GC". Я не уверен, имеет ли это "официальное" имя, поскольку это - что-то, что я только видел в своем собственном коде, и в Какао (см. NSAutoreleasePool в ссылке Какао Apple).

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

Кроме того, как DrPizza я думаю, что ограничение для не использования шаблонов слишком резко. Однако сделавший большую разработку на древних версиях Соляриса, AIX и HP-UX (просто недавно - да, эти платформы все еще живы в Fortune 50), я могу сказать Вам, что, если Вы действительно заботитесь о мобильности, необходимо использовать шаблоны как можно меньше. Используя их для контейнеров и интеллектуальных указателей должен быть в порядке, хотя (это работало на меня). Без шаблонов техника, которую я описал, является более болезненной для реализации. Это потребовало бы, чтобы все объекты, управляемые "коллектором", произошли из общего базового класса.

Хороший день,

Я предложил бы читать соответствующие разделы "Эффективного C++" Scott Meyers. Легкий читать и он покрывает некоторые интересные глюки для захвата неосторожного.

Я также заинтригован отсутствием шаблонов. Так никакой STL или Повышение. Ничего себе.

BTW То, чтобы заставлять людей договориться о конвенциях является превосходной идеей. Как заставляет всех договариваться о конвенциях для OOD. BTW последний выпуск Эффективного C++ не имеет превосходной главы о конвенциях OOD, которые имел первый выпуск, который является жалостью, например, конвенциями, такими как общедоступное виртуальное наследование всегда, моделирует "isa" отношения.

Ограбить

• Когда необходимо использовать, управляют памятью вручную, удостоверьтесь, что Вы звоните, удаляют в том же объеме/функции/классе/модуле, который когда-либо применяется сначала, например:
• Позвольте вызывающей стороне функции выделить память, которая заполнена ею, не возвращайте new'ed указатели.
• Всегда вызов удаляет в том же exe/dll, как Вы назвали новым в, потому что иначе у Вас могут быть проблемы с повреждениями "кучи" (различные несовместимые библиотеки времени выполнения).

Вы могли получить все из некоторого базового класса, которые реализуют интеллектуальный указатель как функциональность (использующий касательно ()/unref () методы и счетчик.

Все моменты, выделенные @Timbo, важны при разработке того базового класса.

Правила:

1. Везде, где возможно, используйте интеллектуальный указатель. Повышение имеет некоторые хорошие.
2. Если Вы не можете использовать интеллектуальный указатель, пустой указатель Ваш указатель после удаления его.
3. Никогда не работайте нигде, который не позволит Вам использовать правило 1.

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