Проверка существования файла в C ++ - PullRequest
3 голосов
/ 02 сентября 2010

В настоящее время я использую что-то вроде:

#include <sys/stat.h>

#include "My_Class.h"

void My_Class::my_function(void)
{
  std::ofstream my_file;

  struct stat file_info; 

  if ( filename_str.compare("")!=0  &&
       stat(filename_str.c_str(),&file_info) == 0 )
  {
    my_file.open(filename_str.data(),std::ios::trunc);
    //do stuff
    my_file.close(); 
  }
  else if ( filename_str.compare("")==0 )
  {
    std::cout << "ERROR! ... output filename not assigned!" << std::endl;
  }
  else
  {
    std::cout << "ERROR! File :" << std::endl
          << filename_str << std::endl 
          << "does not exist!!" << std::endl;
  }
}

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

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

Ответы [ 3 ]

4 голосов
/ 02 сентября 2010

Я бы использовал конструкции boost :: filesystem.Они не только кроссплатформенные, но и являются частью следующей стандартной библиотеки.

3 голосов
/ 02 сентября 2010

В общем, я думаю, что лучше всего просто попытаться открыть его и поймать ошибку.

IMO, проверять разрешения неразумно, потому что, если это окно Linux и вы проверяете его атрибуты, решаете, что не можете писатьк этому, но файловая система поддерживает ACL, и они do дают вам разрешение?(Как системный администратор я не могу стоять , когда приложения делают это. Мне нравятся ACL, и если вы приложение, не говорите мне, что вы не можете писать в файл, если не попробовали сначала.)

0 голосов
/ 02 сентября 2010

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

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

Поэтому, в качестве лучшей практики, я бы предложил открывать файлы экономно (т. Е. Если вы не заинтересованы сразу в содержимом, боретесь с информацией, основанной на атрибутах файлов) И ИЛИ обрабатывать ошибки строго в ответ на фактические вызов, который открывает файл, когда вам это нужно.

...