Гарантируемое удаление файла после завершения программы (C/C++)
1/3 использует целочисленное деление, поскольку обе стороны являются целыми числами.
Вам нужно, по крайней мере, одно из них быть float или double.
Если вы входите значения в исходном коде, такие как ваш вопрос, вы можете сделать 1.0/3; 1.0 является двойным.
Если вы получите значения из других источников, вы можете использовать (double), чтобы int превратить int в double.
int x = ...;
int y = ...;
double value = ((double) x) / y;
6 ответов
Требование, чтобы имя осталось видимым, в то время как процесс работает, делает это трудно для достижения. Можно ли пересмотреть то требование?
В противном случае затем, вероятно, нет идеального решения. Я рассмотрел бы объединение стратегии обработки сигнала с тем, что предлагает Kamil Kisiel. Вы могли отслеживать обработчики сигналов, установленные перед установкой обработчиков сигналов. Если бы обработчик по умолчанию является SIG_IGN, Вы обычно не устанавливали бы свой собственный обработчик; если бы это - SIG_DFL, Вы помнили бы это; если бы это - что-то еще - пользовательский обработчик сигналов - Вы помнили бы, что указатель, и устанавливает Ваше собственное. Когда Ваш обработчик назвали, Вы сделаете то, что необходимо сделать и затем назвать помнивший обработчик, таким образом объединив обработчики в цепочку. Вы также установили бы atexit () обработчик. Вы также зарегистрировали бы это, Вы делаете это и сигналы, для которых Вы делаете это.
Примечание, которые сигнализируют об обработке, является несовершенной стратегией; SIGKILL не может быть пойман, и atexit (), обработчик не назовут, и файл будет разбросан.
предложение David Segond - временный демон имени файла - интересно. Для простых процессов это достаточно; если процесс, запрашивающий временные ветвления файла и, ожидает, что ребенок будет владеть файлом после этого (и выходы) затем, у демона есть проблема при обнаружении, когда последний процесс с помощью него умирает - потому что это автоматически не знает процессы, которые имеют его открытый.
Если Вы просто делаете временный файл, просто создаете его в /tmp или подкаталог этого. Затем приложите максимальное усилие для удаления его при выполнении до atexit(3) или подобный. Пока Вы используете уникальные имена, выбранные до mkstemp(3) или подобный, даже если этому не удается быть удаленным из-за катастрофического отказа программы, Вы не рискуете читать его снова на последующих выполнениях или других таких условиях.
В той точке это - просто проблема системного уровня хранения /tmp чистый. Большинство дистрибутивов вытирает его на начальной загрузке или завершении работы, или выполняет регулярный cronjob для удаления старых файлов.
Возможно, кто-то уже предложил это, но я не могу определить его, учитывая все Ваши требования, лучшему, о котором я могу думать, нужно было передать имя файла так или иначе к родительскому процессу, такому как начинать-сценарий, который вымоется после того, как процесс умирает, имел его, не удался сделать так. Это, возможно, главным образом известно как сторожевой таймер, но затем со случаем более общего использования, добавленным, чтобы уничтожить и/или перезапустить процесс, когда он так или иначе перестал работать.
, Если Ваш родительский процесс умирает также, Вам в значительной степени не повезло, но большинство сред сценария довольно устойчиво и редко умирает, если сценарий не повреждается, который часто легче сохранить корректным, чем программа.
В прошлом я имею, создают "временный файловый менеджер", это отслеживало временные файлы.
можно было бы запросить временное имя файла от менеджера, и это имя было зарегистрировано.
, После того как Вам больше не нужно временное имя файла, Вы сообщаете менеджеру, и имя файла не зарегистрировано.
По получении сигнала завершения, все зарегистрированные временные файлы были уничтожены.
Временными именами файлов был UUID, базирующийся для предотвращения коллизий.
Вы могли иметь ветвление процесса после создания файла и затем ожидать на ребенке для закрытия, и затем родитель может удалить связь с файлом и выходом.
Я только что присоединился к stackoverflow и нашел вас здесь:)
Если ваша проблема заключается в управлении mq-файлами и предотвращении их накопления, вам на самом деле не нужно гарантировать удаление файла после завершения. Если вы просто хотели, чтобы бесполезные файлы копились, то вам может понадобиться вести журнал. Добавьте запись в файл журнала после открытия mq, другую запись, когда она закрыта, и когда ваша библиотека инициализируется, проверьте несоответствие в журнале и примите все необходимые меры для исправления несоответствия. Если вы беспокоитесь о сбое при вызове mq_open / mq_close , вы также можете добавить запись в журнале непосредственно перед вызовом этих функций.