Есть ли способ предотвратить утечку памяти, не обращая внимания разработчиков на C ++ - PullRequest
2 голосов
/ 23 февраля 2012

В настоящее время у нас есть несколько способов предотвратить утечку памяти, такие как

  1. прокси (shared_ptr, auto_ptr) и
  2. метод учета,
  3. сборка мусора (java)

Но первый требует значительных накладных расходов от разработчиков, а второй вызывает большие накладные расходы.

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

Ответы [ 3 ]

7 голосов
/ 23 февраля 2012

Есть ли способ предотвратить утечку памяти, не прося разработчиков обратить на нее дополнительное внимание в C ++?

Использовать минимальные динамические выделения, выполнять только тогда, когда это строго необходимо .
Если вы используете динамическое распределение, вам придется подчиняться той цене, с которой он идет, и которая справляется с этим правильно. Лучший способ сделать это - использовать RAII в C ++. Обратите внимание, что написание кода RAII не тривиально, но с практикой его можно привыкнуть думать в RAII.

0 голосов
/ 23 февраля 2012

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

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

Кроме того, напишите более полные интерфейсы, чтобы дать подсказки, например:

class DataWrapper
{
public:
    const BYTE* PeekAtData() const;        
    BYTE* RemoveData();
....
};
0 голосов
/ 23 февраля 2012

Хорошо, хорошая практика кодирования становится хорошим программированием привычки , и тогда для их использования требуется очень мало "внимания". Я бы предложил использовать объекты-оболочки RAII, такие как std :: unique_ptr, std :: shared_ptr, наряду с четкими рекомендациями о том, когда и где следует использовать динамическое размещение.
Хорошее начало: если вы видите, что кто-то печатает слово delete, то это должен быть флаг, с которым вам нужно быть очень осторожным.

Это подводит меня ко второму пункту: не используйте динамическое размещение (если это абсолютно необходимо), используйте как можно больше автоматически уничтожаемых объектов, контролируемых областью действия. НИКОГДА new объект RAII, и это заставит вас задуматься о том, как следует обрабатывать объект, который переносит владелец RAII, если изменяется область действия.

Например:

std::auto_ptr<Foo> ptr2Foo( new Foo() );
...
...
if(ptr2Foo->isValidNow())
    passToOwningObject(otherObject, ptr2Foo);
//now when scope ends the newed Foo will be destroyed or owned
//by an appropriate object.

или

std::unique_ptr<Foo> ptr2Foo( new Foo() );
...
...
if(ptr2Foo->isValidNow())
    passToOwningObject(otherObject, std::move(ptr2Foo));
//now when scope ends the newed Foo will be destroyed or owned
//by an appropriate object.

И регулярно запускать анализ кода (MSVC, Valgrind, Coverity и т. Д.) И не игнорировать предупреждения компилятора.

...