Не даст ли такое поведение дополнительный чрезмерный оверхед, или, может, наоборот, в некоторых сложных случаях позволит на 5 копеек увеличить быстродействие?

Это пока твоя утилита не превратилась в неюниксвейный комбайн, и кто не решил что код нужно реюзать...

Если это модуль синглтон с функциями init, destroy и instance, то валяй. Вот только что тебя останавливает от того что бы таки освободить память?

Увеличить быстродействие чего? Разве что завершаться программа будет на 5 копеек быстрее.

предполагается, что вся её жизнь — в некотором роде, завершение)

за разумное время она всё равно завершит свою работу

если вы твёрдо уверены что программа в скором времени каюк, то да, освобождать память через free не стоит.

но есть пара других нюансов:

1) программа зиждется на библиотеках/модулях/классах/компонентах/блоках и в них освобождать память таки надо. Для С - если в пределах одного .c файла память выделялась, то где-то в этом-же файле освобождается.

2) просто культура - если прям следом со 100% уверенностью, в любос случае, не следует exit то память надо освобождать.

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

valgrind

привыкнешь получать простыню за которой могут скрываться реальные баги.

освобождение памяти избавит от багрепортов, если кто-то решит погонять программу под соответствующими утилитами.

Это пока твоя утилита не превратилась в неюниксвейный комбайн, и кто не решил что код нужно реюзать...

предполагается, что не превратится

Вот только что тебя останавливает от того что бы таки освободить память?

допустим, она в процессе работы создаёт куда больше объектов, которые друг на друга указывают, создавая посредством указателей сложный граф. все эти объекты создаются внутри каких-то методов динамически и их удаление становится нетривиальной задачей. может, оставив после использования этот набор объект как есть, получаем выигрыш не только времени на набор кода, но и небольшой по скорости без отрицательных сторон такого решения?

Имеет. Так сделано, например, в qemu. Но делать так надо очень осторожно.

Ну не знаю, как по мне, это несоблюдение как минимум правил хорошего тона.

В ответ на основной вопрос - можно, но лично я бы, такое увидев расстроился, хотя кому какое дело до моей ронимой души :)

А если не секрет что за утилита?

Где-то читал историю, про то как отработавший 20 дней cp потом ещё более суток освобождал свою память перед завершением. Так и не дождались, прибили.

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

Можно. Я всегда так делаю.

Так сделано, например, в qemu.

И в Chromium. И, возможно, в Firefox. У него в инструкциях предлагается собирать его для запуска под valgrind с особыми флагами, и это кроме отключения jemalloc.

А если не секрет что за утилита?

да у меня в последнее время много таких — включил, отработало и выключилось.

valgrind корректно отрабатывает такие сценарии, если только специально --show-reachable=yes не указывать.

Перепись быдлокодеров итт.

Расскажи, в чем может быть причина не освобождать память явно?

тред прочитайте, тут всего полстраницы

в процессе работы создаёт куда больше объектов, которые друг на друга указывают, создавая посредством указателей сложный граф

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

Здесь уместно процитировать Линуса:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

если твои структуры данных настолько запутанные,

как ещё представить произвольный граф с минимальным оверхедом по скорости и памяти?

Минимальный оверхед - почти всегда не самое лучшее решение (если только это не «илитный запил»). Скорость надо выигрывать на хороших и понятных алгоритмах. Не зацикливайся на преждевременной оптимизации.

«А может? Не советую. А вот это можно попробовать, выполняйте» типа того. В общем не надо на это рассчитывать ;) Не повторяйте дома.

Минимальный оверхед - почти всегда не самое лучшее решение

c++ для того и создан, чтобы обеспечивать минимальный оверхед

Скорость надо выигрывать на хороших и понятных алгоритмах

ок. как бы вы реализовали произвольный граф?

произвольный граф

произвольные графы бывают только в произвольных программах

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

Как бы я реализовал: хранить адреса нод в списке, при необходимости (в т.ч. при дебаге) - весь граф как на ладони. При очистке памяти - пройтись по списку.

Да. Видел такое в некоторых CGI приложениях.

Перепись быдлокодеров

И только дартаньяны делают так:

int main()
{
  int *p = malloc ....
  ....
  free(p);
  p = NULL;
  return 0;
}

произвольные графы бывают только в произвольных программах

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

в списке? это +16 байт на каждую ноду. учитывая, что размер ноды, как правило, небольшой, получаем оверхед на память порядка 10-30%.

лучше, с этой точки зрения — массив, но при необходимости расширения графа расширение массива станет накладной операцией.

учитывая, что размер ноды <...> небольшой

В таком случае всё равно будет лучше запилить свой slab-like аллокатор. А когда ты его запилишь, освобождение памяти станет тривиальным — просто грохнуть всю созданную арену (она же «кэш», в терминах вики).

Прочитал, не нашел ответа на свой вопрос. Весь тред просто кричит о том, что это целенаправленная стрельба в ногу.

Нет. За это надо отдавливать пальцы. Сам себе вероятные ошибки пишешь.

А какой смысл освобождать объект, если ты знаешь что рпограмма без этого объекта работать не может? Тут наоборот хорошим тоном будет _убрать_ любую возможность освободить память из-под этого объекта.

Нет смысла освобождать память перед завершением программы — второе включает в себя первое в любой ОС.

в списке? это +16 байт

+8, т.к. sizeof(ptrdiff_t)==8 или 4. Ну и список пригодится для многого другого, помимо удаления.

например, поиск оптимального пути на карте

и как ты будешь искать «путь до музея», если не можешь получить список музеев?

Нет смысла освобождать память перед завершением программы — второе включает в себя первое в любой ОС.

смысл в том, что ПЕРЕД завершением программы _ничего_ нельзя будет дописать дополнительно.

Обычный говнокод у тебя получится, который write only.

write-only код выйдет.

+8, т.к. sizeof(ptrdiff_t)==8 или 4.

Думаю, он имел в виду связный список.

один дурак сказал, другой повторяет

Третий дурак под анонимом комментирует.

комментировать некомпетентных дураков - это ведь так занимательно

понимаю, что чувствуют коментаторы российского футбола

двусвязанный? А зачем?

один дурак сказал, другой повторяет

ваше мнение очень важно для нас.

смысл в том, что ПЕРЕД завершением программы _ничего_ нельзя будет дописать дополнительно.

Это не просто тупорылый высер анскильной обезьяны, это несвязный бред шизоида. Расскажи, в чем СМЫСЛ? ПЕРЕД завершением программы что-то дописывать. И почему это нельзя будет сделать. И причем тут ридонли, как это затрудняет чтение, макака?

Расскажи, в чем СМЫСЛ?

ты всё равно не поймёшь. Иди дальше float'ы складывай друг с другом, и радуйся, как оно быстро в SSE получается, скильный ты наш…

Нет, я имел в виду односвязный список, который хранит указатель на последующий элемент списка + указатель, собственно, на данные. выходит 2*8 = 16, байт. emulek

двусвязанный?

Почему сразу дву-?

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

комментаторы футбола хотя-бы правила футбола знают, в отличие от тебя.

Нет, я имел в виду односвязный список, который хранит указатель на последующий элемент списка + указатель, собственно, на данные. выходит 2*8 = 16

почему ТС не может в ноде сделать поле «next», превратив таким образом эти ноды в список? Тогда получится 8 байт, что немного. Хотя конечно можно и так оставить, но тогда это будет говнокод, который невозможно поддерживать.