LINUX.ORG.RU

хочу писать красиво :)


0

0

Здравствуйте. Недавно, читая чужой код, наткнулся на такую вещь: человек, натолкнувшись на ошибку в программе, которая в рантайме не правится (память не выделилась, файл не открылся...) выдаёт ошибку и выходит по exit(EXIT_FAILURE). Я то, как умная Маша, пробегался по выделенной ранее памяти, освобождал её, закрывал все открытые файлы, выходил на уровень выше (по дереву вызовов) return`ом с возвращением кода ошибки - там та же фигня и т.д.... Я был в корне не прав? На сколько я понимаю, при вызове exit() освобождается вся выделенная программе память и закрываются файловые потоки, Но так как делал я, мне как-то спокойнее было :)) (паранойя?) Может кто-нибудь может назвать причины, почему стоит делать именно так, как делал я? :)

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

И ещё вопрос - зачем делать:

my_type_t * var;

var = (my_type_t *) malloc (sizeof(my_type_t));

Когда можно:

var = malloc (sizeof(*var));

- Преобразование типа перед возвратом malloc имеет какое-то сакральное значение (подозреваю - для совместимости с C++)

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

Встречал также

ioctl (fd, MY_CONTROL_COMMAND, (int)&my_var).

Здесь-то к чему эти преобразования???

anonymous

> Я был в корне не прав?

При завершениии процесса все его ресурсы освобождаются ядром

mv ★★★★★
()

> Я был в корне не прав?

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

> Может кто-нибудь может назвать причины, почему стоит делать именно так, как делал я?

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

> var = (my_type_t *) malloc (sizeof(my_type_t));

- Преобразование типа перед возвратом malloc имеет какое-то сакральное значение (подозреваю - для совместимости с C++)

Лень проверять, а разве в C можно void* в my_type_t* преобразовывать неявно? Если можно, то, конечно, не нужно преобразовывать. Я на автомате пишу обычно.

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

Нет скрытого смысла, всегда лучше по переменной или по первому элементу массива.

> ioctl (fd, MY_CONTROL_COMMAND, (int)&my_var).

> Здесь-то к чему эти преобразования???

Ну как зачем? Чтобы были лишние проблемы при портировании на системы, где sizeof(void*) > sizeof(int) :)

Legioner ★★★★★
()

Писай, кто тебе не даёт?

anonymous
()
Ответ на: комментарий от Legioner

>> Я был в корне не прав?

> Зависит от ситуации. Результат всегда один и тот же, но твой подход правильней, вообще говоря. В общем здесь баланс между качеством и скоростью разработки.

Чем этот подход правильнее?

smh ★★★
()
Ответ на: комментарий от smh

Я уже показал. Если завтра надо будет удалять pid-файл, созданный выше по стеку, то придётся переписывать с кодами возврата.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

>Лень проверять, а разве в C можно void* в my_type_t* преобразовывать неявно?

можно. (void *) можно присвоить любому указателю. и любой указатель можно присвоить (void *)'у. в c++ нельзя, ругается. отсюда и приведения.

anonymous
()

если не будешь нормально высвобождать ресурсы то столкнёшься с тем что какой-нить valgrind будет упорно находить memory leaks. С точки зрения конечного пользователя программы один хрен.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

твой подход правильней еще и потому, что когда ты свой кусок кода захочешь объединить с другой программой, выполняющейся постоянно (демон, например), тебе не прийдется ломать голову, с какой стати комп начал тормозить после N суток работы...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.