Вариант 1 .
Самый простой способ - полностью избежать new
и delete
.
Вместо:
blockquote>b = new int; b = new int; delete b;
Запись:
std::unique_ptr
b; ... b = std::make_unique (); b = std::make_unique (); Когда
b
перезаписывается или выходит из области видимости, он освобождает память , Нетdelete
требуется или даже разрешено. Обратите внимание, что это похоже на сборщик мусора Java, но в большинстве случаев достаточно хорошо.Вариант 2.
Другой способ - использовать дополнительный сборщик мусора , но это решение не рекомендуется. Во-первых, сборщик мусора является консервативным, то есть существует вероятность утечки памяти, несмотря на сборщик мусора. Во-вторых, эти решения имеют тенденцию усугублять существующие проблемы, поскольку утечки памяти не будут замечены и устранены при появлении. Лечение утечек памяти через год после введения на несколько порядков сложнее, чем лечение через час после введения.
ПРИМЕЧАНИЕ : Использование
unique_ptr
не так безопасно, как в языках с сборкой мусора, таких как C #, Java и Python. Он терпит неудачу, когда нет четкой модели владения и когда существует круговое владение. Если элементa
имеетunique_ptr
-b
, аb
имеетunique_ptr
-a
, то они никогда не будут освобождены. Они никогда не будут освобождены, посколькуunique_ptr
освобождает объект в деструкторе, но никто не вызовет деструктор ниa
, ниb
. Если никто не вызывает деструктор, тоunique_ptr
никогда не удалит объект и никогда не вызовет деструктор другого объекта.ПРИМЕЧАНИЕ 2 : Иногда вместо
unique_ptr
следует использоватьstd::shared_ptr
, но это не решает проблему циклических ссылок. Это только решает проблему нескольких владельцев одного объекта.ПРИМЕЧАНИЕ 3 : Эти интеллектуальные указатели не снижают вероятность переполнения стека из-за глубокой рекурсии в деструкторах. Это может произойти при рекурсивном уничтожении длинных связанных списков или в несбалансированных бинарных деревьях. Использование
unique_ptr
для этого случая просто скрывает тот факт, что рекурсия имеет место.
Честно говоря, я всегда делаю свое кодирование свободного времени в язе (например, код:: блоки, моноразработайте, anjuta) или редактор (фактически всегда scite), и компиляция, которую я делаю в терминале через make-файл (рукописный, cmake, автоделают).
Это не действительно проблема w.r.t. время для компиляции: F7 (или некоторые другие из ключей F) по сравнению с (alt+tab, входят), где (alt+tab) и нажимаются почти одновременно, но я извлекаю большую пользу из наличия до полноэкранных отчетов компилятора и часто я так или иначе тестирую свои программы в терминале. Кроме того, это делает мой код более независимым от IDE (когда-либо пытался получить make-файл из кода:: блоки в целях распределения?).
Компилятор Visual Studio называют cl.exe, и компоновщиком является link.exe. Они присутствуют в особенности каталоги Visual Studio. Из Visual Studio> свойства проекта> C++> Командная строка, или путем отключения опции "Suppress Banner" там, можно найти команду той Visual Studio выполнения. Можно назвать эти командные строки из netbeans.
Получение всех имен файлов в список скомпилировать может быть более хитрым. Вам нужна система сборки для этого. Можно попытаться использовать тот же механизм, который Visual Studio использует, но извините мои сбои знаний там. С другой стороны, можно использовать CMake или некоторую другую систему сборки. Затем каждый раз, когда Вы добавляете/удаляете исходный файл, необходимо было бы обновить CMakelist.txt, чтобы смочь скомпилировать.
Вы можете получить подсветку синтаксиса, графическое отображение кода и т.д. из netbeans без установленного компилятора, я думаю (не уверен, вам может понадобиться cygwin или mingw для синтаксического анализа). Что вы должны сделать, так это создать хотя бы пустой make-файл. Если вы хотите использовать компилятор Microsoft, вам либо необходимо:
a) Написать make-файл самостоятельно для компиляции всего с помощью cl б) Вызовите msdev из make-файла с именем проекта, и он все скомпилирует б) Вызовите что-то вроде scons из make-файла, чтобы скомпилировать все
Я использую netbeans для разработки кроссплатформенного программного обеспечения, хотя в настоящее время я фактически не запускаю сборки из netbeans.