Ниже приведен код для того же случая.
#include <iostream>
#include <fstream>
using namespace std;
int main () {
ofstream myfile;
myfile.open ("example.txt");
myfile << "Writing this to a file.\n";
//myfile.close();
return 0;
}
Какая разница, если я раскомментирую строку myfile.close()?
Нет никакой разницы. Деструктор файлового потока закроет файл.
Вы также можете положиться на конструктор, чтобы открыть файл вместо вызова open(). Ваш код можно сократить до этого:
#include <fstream>
int main()
{
std::ofstream myfile("example.txt");
myfile << "Writing this to a file.\n";
}
std::ofstream("example.txt")<<"Writing this to a file.\n";
- person Deduplicator; 01.02.2015
Чтобы подкрепить ответ juanchopanza ссылкой на std::fstream документацию
(деструктор)
[виртуальный](неявно объявленный)уничтожает basic_fstream и связанный с ним буфер, закрывает файл (виртуальная общедоступная функция-член)
В этом случае ничего не произойдет и время выполнения кода очень меньше.
Однако, если ваши коды работают в течение длительного времени, когда вы постоянно открываете файлы и не закрываете их, через определенное время может произойти сбой во время выполнения.
когда вы открываете файл, операционная система создает запись для представления этого файла и хранения информации об этом открытом файле. Таким образом, если в вашей ОС открыто 100 файлов, то в ОС будет 100 записей (где-то в ядре). Эти записи представлены целыми числами, такими как (...100, 101, 102....). Этот номер записи является дескриптором файла. Таким образом, это просто целое число, которое однозначно представляет открытый файл в операционной системе. Если ваш процесс открывает 10 файлов, ваша таблица процессов будет иметь 10 записей для файловых дескрипторов.
Кроме того, именно поэтому у вас могут закончиться файловые дескрипторы, если вы открываете много файлов одновременно. Что предотвратит запуск систем *nix, поскольку они постоянно открывают дескрипторы для заполнения /proc.
Аналогичная вещь должна произойти в случае всей операционной системы.
stdin, stdout и stderr.
- person ElementW; 31.01.2015
close для этой игрушечной программы не существенно изменит общее время ее выполнения. Деструктор вызывает close, а close ничего не делает, если он уже был вызван, так что разница порядка 10 дополнительных машинных инструкций.
- person zwol; 01.02.2015
HANDLE — это typedef для void * только для обратной совместимости; значение HANDLE функционально является целым числом. (В Win16, если мне не изменяет память, HANDLE были настоящими указателями на структуры данных ядра, но в Windows NT они были сделаны непрозрачными значениями, и поэтому все производное от них.) И, хотя я не могу найти, что это такое прямо сейчас, Я уверен, что существует ограничение на количество открытых файлов для каждого процесса. Однако вы правы в том, что это не маленькие целые числа, а значения 0, 1, 2 не являются специальными (вместо них есть другие специальные значения).
- person zwol; 01.02.2015
HANDLE имеют значение, два младших бита которого равны нулю.
- person zwol; 01.02.2015
main(), а затем войдете в основной цикл программы, не имеет значения, что файл будет автоматически закрыт при выходе из программы: вы фактически слили дескриптор файла. Точно так же, если ваша программа поддерживает список открытых файлов и не заботится о его очистке, деструктор не будет вызываться до тех пор, пока файл не будет удален из списка — до тех пор, пока дескриптор не будет фактически утерян.
- person Mark; 01.02.2015
В обычных условиях разницы нет.
НО в исключительных случаях (с небольшими изменениями) вызов закрытия может вызвать исключение.
int main()
{
try
{
ofstream myfile;
myfile.exceptions(std::ios::failbit | std::ios::badbit);
myfile.open("example.txt");
myfile << "Writing this to a file.\n";
// If you call close this could potentially cause an exception
myfile.close();
// On the other hand. If you let the destructor call the close()
// method. Then the destructor will catch and discard (eat) the
// exception.
}
catch(...)
{
// If you call close(). There is a potential to get here.
// If you let the destructor call close then the there is
// no chance of getting here.
}
}
