SomeClass(..xx..); //just initialization
while (...) {
if(pointer) delete pointer;
pointer = new SomeClass(..yy..);
...
}
delete pointer;
2. А вот такой код:
SomeClass *pointer = new SomeClass(..x....); // just initialization
while(...) {
SomeClass *pointer = new SomeClass(..y....);
}
delete pointer;
Работает и даже память не течет. Вопрос почему это так?
у меня такой код не сегфолтится int *pointer = new int(1); //just initialization if(pointer) delete pointer; pointer = new int(1); delete pointer;
Весь код можно увидеть из 1 пункта?
А, ты уже смотришь, расскажи потом тогда
HepMC::GenVertex *sub_vertices = new HepMC::GenVertex(HepMC::FourVector(0, 0, 0, 0), 0); // just initialization while (ihy < hj2->GetNtot()) { if ((hj2->GetiJet().at(ihy)) != isub_l) { if(sub_vertices) delete sub_vertice; sub_vertices = new HepMC::GenVertex(HepMC::FourVector(0, 0, 0, 0), hj2->GetiJet().at(ihy)); Да, возможно вопрос сложнее, чем я думал. Или нужен прямо совсем весь код?
Скинь на pastebin код (функцию) и ссылку скинь или ты можешь сам в отладчике пошагово пройтись и посмотреть выполняются ли ветки как задуманно, а вообще, используй unique_ptr если не хочешь утечек памяти
Код есть на GitHub, но он огромен. Наверное мой вариант через unique_ptr, спасибо за совет!
Кто ж знает-то? можно определённо сказать одно: Один кусок кода более правильный , другой -неправильный.
И какой не правильный? Если 2., то почему компилятор и llvm-analyzer не ругаются?
Ты прислал два отрывка кода. Даже не так - два обрывка кода. Ты реально думаешь, что возможно оценить их правильность?
Попробуй скормить этим два куска твоим анализаторам, что они скажут?
Для таких ситуаций существуют отладчики. Если не умеете ими пользоваться - научитесь: однозначно пригодится.
Спасибо, хороший совет
А ничего, не ругаются в том смысле, что память не течет
Я не про это. А про то, что такой обрывок, ещё и с удалёнными частями, невозможно анализировать.
Да, я понял, спасибо. Буду с поведением фреймворка разбираться.
while(...) { SomeClass *pointer = new SomeClass(..y....); } delete pointer; // вот этот pointer — это другой pointer, другая переменная с тем же именем, нежели переменная в цикле. Она ни в коем случае не удалит ничего, на что ссылается переменная с именем pointer в цикле. Это ожидаемое тобой поведение ? Ты на это рассчитывал?
который фреймворк кстати?
В этом и был вопрос: почему компилятор не ругаться на редекларацию, и почему llvm-analyzer не видит утечки памяти тут
С чего он должен?
Внутренний корпоративный
Я не могу оценить есть ли там утечка памяти
А ты если утечки ищешь, то использовал бы тут unique_ptr, и всё бы автоматом освобождалось.
Да, это был хороший совет, спасибо
Собственно пора уже привыкать жить без new/delete
Ну, по тому коду что ты показал, там вообще не надо было бы создавать объекты динамически...
Почему? Конструктор запускается с разными вводными... Вне цикла инициализация по-умолчанию, в цикле - условная
Потому что ты объект тут же удаляешь. Это значит, что время жизни обьекта строго определено.
Там ещё условие, т. ч. объект может жить несколько циклов
Да с ними уже лет 20 в C++ никто и не живет, кроме тех случаев, когда фреймворк (например, Qt) не берет на себя GC
Старые коды переписываются медленно... Да и auto_ptr работало не очень (при копировании)
Не то чтобы не очень, оно работало по стандарту и было не Copyable
Ты лучше расскажи, когда тебя заморозили? Разморозка недавно была, это понятно.
Вот поэтому в больших и сложных проектах особого желания отказываться от new/delete не было
Повторю, что использовать неуправляемые raw указатели в C++ - это говорит о качестве "большого проекта"
Нестандартных и своих смарт указателей было выше крыши
Сырых new/delete, указатели то за что
Ну хрен знает, всякие графы, двух связанные списки без raw не реализуешь
Контейнеры "это другое" tm
Использовать raw указатели или владеющие raw указатели?)
Обсуждают сегодня