[неуч][c/c++] Об утечках памяти

нужно перестать мешать C и C++ и, в твоём случае, сделать delete [] var;

Да, но вообще то так не делают. В С++ память освобождает тот, кто выделял, т.е. либо по деструктору класса, либо почитайте про smart pointer. В С я не спец, но ИМНО память вначале ф-ии выделяете, потом куда то отдаете и ее там юзают, потом в конце ф-ии освобождаете.

> В С я не спец, но ИМНО память вначале ф-ии выделяете, потом куда то отдаете и ее там юзают, потом в конце ф-ии освобождаете.

Если another_function() порождает объект, то она же и память под него выделяет. Такой аналог конструктора.

п%ц

Б-же, сделай меня развидеть это...

ИМНО так вот и создают утечки... если в начале области видимости стоит malloc, то понятно что в конце должен чтоять free. Но когда вначале стоит некая ф-я, то ХЗ нужно free вызывать, не нужно... Я не говорю что оно рабоать не будет, но ИМНО это ужасный дизайн.

Да, че то лажу написал, но идея должна быть ясна.

Пдобное по-моему обычно оформляется так:

T *another_create(...);
void another_delete(T*);

При использовании соблюдается правило «я тебя породил, я тебя и убью». Если делать так как ты, в вызывающем коде легко зафейлить и вместо delete[] сделать delete или free.

Не обязательно: есть функции, выделяющие память внутри себя и возвращающие указатель на эту область (напр., strdup). О free должна позаботиться функция, которая эту функцию вызывает, либо деструктор.

Будет сегфолт наверное...

>> Не обязательно: есть функции, выделяющие память внутри себя и возвращающие

указатель на эту область (напр., strdup). О free должна позаботиться функция, которая эту функцию вызывает, либо деструктор.

Но это же моветон и ССЗБ

> ИМНО так вот и создают утечки... если в начале области видимости стоит malloc, то понятно что в конце должен чтоять free. Но когда вначале стоит некая ф-я, то ХЗ нужно free вызывать, не нужно... Я не говорю что оно рабоать не будет, но ИМНО это ужасный дизайн.

Неправильно ты, дядя Фёдор, бутерброд ешь.

В приплюснутом коде у тебя есть new, порождающий объект в куче, и есть delete, сносящий объект.

В Си у тебя есть производящая функция, порождающая объект в куче, и есть деинициализирующая функция, сносящая объект. Отвечать за удаление объекта обязан тот, кто вызвал производящую функцию. Инкапсуляция десу.

А вот низкоуровневые игры «я тебе указатель на память дам, а ты мне в ней что-нибудь нарисуй» как раз до добра не доводят. Если, конечно, это не взаимодействие с ядром, где иначе никак.

Никакой это не моветон, а очень даже удобно. Особенно если функция должна заполнить эту область памяти.

Заодно сам спрошу: если во время выполнения блока произошло исключение, для экземпляров классов в локальных переменных вызывается деструктор?

Сделаешь delete [] когда будет надо убрать var и ненадо городить шаблоны да бусты всякие. И да, четко раздели для себя c/c++ на с и с++.

Вообще на лиспе ты бы с такой ерундой не столкнулся.

Если раскрутка приводит к выходу за пределы блока, то да.

Во-первых если используешь new [], то освобождать надо через delete []. Во-вторых в C++ new это «матерное» слово и использовать его в 99.99% случаев не надо. Все проблемы с утечками решаются с помощью RAII, стандартных контейнеров и умных указателей.

а чем vector < char > не угодил? на кой сюда буст?

При передаче вектора копирования не происходит?

> При передаче вектора копирования не происходит?

man RVO

Во-вторых в C++ new это «матерное» слово и использовать его в 99.99% случаев не надо.

кто-то путает C++ и Java?

Отставить панику, оно не скомпилируется:

<stdin>: В функции ‘char* another_function()’:
<stdin>:4:41: ошибка: запрошено преобразование от ‘char*’ к нескалярному типу ‘std::auto_ptr<char>’
<stdin>:6:10: ошибка: ошибка преобразования ‘std::auto_ptr<char>’ в ‘char*’ в return

Нет, он всё правильно говорит. new не нужен, а за delete вообще надо сажать как за экстремизм. Ессно к разработчикам либ и тем, кому реально надо оптимизировать это не относится.

>>А вот низкоуровневые игры «я тебе указатель на память дам, а ты мне в ней что-нибудь нарисуй» как раз до добра не доводят.

Доводят, доводят, если руки растут откуда надо, и матчасть освоена. Как раз в примере ТС-а такую мелочь как char[10] можно создать на стеке в function и закинуть указатель в another_function. Со стек фреймом у вызывающей функции ничего не случится, пока она не завершит свою работу.
Разве что нужно быть аккуратным и не забываться, чтобы не передать этот указатель куда-нибудь налево. Но это со временем приходит.
А частое резервирование памяти на куче по мелочи приводит к ее фрагментации. И потом будете ловить совсем не очевидные баги.

Нет, он всё правильно говорит. new не нужен

ну и, собственно, обоснуй

> А частое резервирование памяти на куче по мелочи приводит к ее фрагментации. И потом будете ловить совсем не очевидные баги.

Логика-логика, где ж ты потерялась.

> Отставить панику, оно не скомпилируется:

это было очевидно

Во-первых компилятор может оптимизировать, а во-вторых передачу по ссылке никто не запрещал.

В Java как раз без new никуда, а в C++ можно жить.

Хм... а в gtk+ часто так. Вызываешь функцию, она тебе чего-то там создает, а потом ты сам должен сделать g_free(), когда созданное больше не нужно.

Зачем самому возиться с выделением/освобождением памяти, а потом бороться с утечками, если есть средства языка и стандартной библиотеки, которые позволяют этого избежать?

есть средства языка и стандартной библиотеки, которые позволяют этого избежать

у меня есть ощущением, что я понимаю о чём идёт речь, но моск после работы совсем ватный, не поясните на примере, плиз?

если совсем на пальцах, то вот примеры

вот это

void func()
{
  A * a = new A ();
  /// do smth ...
  delete a;
}

void func()
{
  auto_ptr < A >  a(new A ());
  /// do smth ...
}

вот это

A * get_data()
{
   return  new A[100];
}

void func()
{
 A * a = get_data();
 // do smth ...
 delete [] a;
}

vector < A > get_data()
{
   return  vector < A > (100);
}

void func()
{
 vector < A  > a = get_data();
 // do smth ...
}

не нужно. нужно делать delete [] str. причём не обязательно «в конце function()»

Вот-вот, а я на все эти gtk насмотрелся, и сам в некоторых функциях стал выделять память и возвращать ее. Хотя, это имеет смысл делать лишь в функциях-инициализаторах, или функциях, сильно изменяющих переданную им область памяти (в т.ч. ее размер) - тогда есть смысл делать аргумент указателем на указатель...

>В Java как раз без new никуда, а в C++ можно жить.

Это смотря в каком С++. При использовании Qt например без new никуда не деться. В общем утверждение очень спорное, понятно, что дергать вручную кучу почем зря не стоит, но и доводить идею до идиотизма тоже глупо.

>auto_ptr < A > a(new A ());

new осталось. fail засчитан.

для qobject'ов есть reference counter

считай, что там не new, а MegaSuperFactory::CreateObject

А на что передавать ссылку при возвращении значения?

Возвращай по значению. Это не так страшно как кажется. В 99.99% случаев реально никакого копирования не случится.

И не спроста в стандарте кодирования гугла указано, что результат функций возвращаются ТОЛЬКО по значению через return, а не через аргументы.

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

А я у себя в некоторых местах, где нужно создать относительно большой массив байт, который потом может утечь куда угодно, использовал boost::shared_ptr<std::vector>. Это не очень плохо?

Выглядит подозрительно. Смотреть конкретную ситуацию нужно. Мне обычно удавалось избегать подобных ситуаций.

Данные — распакованное изображение. Используется разными объектами при рисовании, объекты могут копироваться, храниться, перемещаться, пока кому-то нужна текстура — она должна быть в памяти.

Тогда всё ok.

Ну да, конец поста в спешке дописывал, логика пропала. Как раз вспомнилось, что на фрагментированной памяти malloc в какой-то из старых MSVC начинал дико себя вести. Не известно, почему это проявлялось, но тем не менее крови попортило.