filesystem
Incluya el encabezado <filesystem> para tener acceso a las clases y funciones con las que se manipula y recupera información sobre las rutas de acceso, los archivos y los directorios.
Sintaxis
#include <filesystem> // C++17 standard header file name
#include <experimental/filesystem> // Header file for pre-standard implementation
using namespace std::experimental::filesystem::v1;
Importante
Cuando se publicó Visual Studio 2017, el encabezado <filesystem> aún no era un estándar de C++. C++ en Visual Studio 2017 RTW implementa el borrador final del estándar, que se encuentra en ISO/IEC JTC 1/SC 22/WG 21 N4100. Visual Studio 2017, versión 15.7 y posteriores, admite el nuevo estándar de C++17 <filesystem>.
Se trata de una implementación completamente nueva, incompatible con la versión anterior std::experimental. Fue necesario debido a la compatibilidad con symlink, correcciones de errores y cambios en el comportamiento estándar requerido. En Visual Studio 2019, versión 16.3 y posteriores, incluir <filesystem> solo proporciona el nuevo std::filesystem. Incluir <experimental/filesystem> proporciona solo la implementación experimental anterior. La implementación experimental se quitará en la próxima versión sin ABI de las bibliotecas.
Este encabezado admite sistemas de archivos para uno de dos tipos amplios de sistemas operativos host: Microsoft Windows y POSIX.
Mientras que la mayoría de las funciones son comunes a ambos sistemas operativos, en este documento se identifican las diferencias. Por ejemplo:
Windows admite varios nombres de raíz, como
c:o\\network_name. Un sistema de archivos consta de un bosque de árboles, cada uno con su propio directorio raíz (por ejemplo,c:\o\\network_name\), y cada uno con su propio directorio actual, para completar una ruta de acceso relativa (una que no es una ruta de acceso absoluta).POSIX admite un único árbol, sin nombre de raíz, el directorio raíz único
/y un único directorio actual.
Otra diferencia importante es la representación nativa de rutas de acceso:
Windows usa una secuencia terminada en null de
wchar_t, codificada como UTF-16 (uno o varios elementos para cada character).POSIX usa una secuencia terminada en null de
char, codificada como UTF-8 (uno o varios elementos para cada character).Un objeto de
pathde clase almacena la ruta de acceso en forma nativa, pero admite la conversión sencilla entre esta forma almacenada y varias formas externas:Una secuencia terminada en null de
char, codificada según la preferencia del sistema operativo.Una secuencia terminada en null de
char, codificada como UTF-8.Una secuencia terminada en null de
wchar_t, codificada según la preferencia del sistema operativo.Una secuencia terminada en null de
char16_t, codificada como UTF-16.Una secuencia terminada en null de
char32_t, codificada como UTF-32.
Las interconversiones entre estas representaciones se realizan, según sea necesario, mediante el uso de una o varias facetas
codecvt. Si no se especifica un objeto de configuración regional específica, estas facetas se obtienen de la configuración regional global.
Otra diferencia es el detalle con el que cada sistema operativo permite especificar permisos de acceso a archivos o directorios:
Windows registra si un archivo es de solo lectura o editable, un atributo que no tiene sentido en el caso de los directorios.
POSIX registra si un archivo se puede leer, escribir o ejecutar (examinar, si es un directorio). Además, si se permite cada operación para el propietario, el grupo del propietario o para todos, además de algunos otros permisos.
Un aspecto común a ambos sistemas es la estructura impuesta en una ruta de acceso una vez superado el nombre de raíz. Para el nombre de la ruta de acceso c:/abc/xyz/def.ext:
El nombre de raíz es
c:.El directorio raíz es
/.La ruta de acceso raíz es
c:/.La ruta de acceso relativa es
abc/xyz/def.ext.El elemento primario es
c:/abc/xyz.El nombre de archivo es
def.ext.La raíz es
def.La extensión es
.ext.
Una diferencia menor es el separador preferido, entre la secuencia de directorios de una ruta de acceso. Ambos sistemas operativos le permiten escribir una barra diagonal /, pero, en algunos contextos, Windows prefiere una barra diagonal inversa \. La implementación almacena su separador preferido en el miembro de datos preferred_separator en path.
Por último, los objetos path tienen una característica importante: pueden usarse cada vez que se necesite un argumento filename en las clases definidas en el encabezado <fstream>.
Para obtener más información y ejemplos de código, vea Exploración del sistema de archivos (C++).
Miembros
Clases
| NOMBRE | Descripción |
|---|---|
Clase directory_entry |
Describe un objeto devuelto por un directory_iterator o recursive_directory_iterator y que contiene una path. |
Clase directory_iterator |
Describe un iterador de entrada que establece una secuencia por los nombres de archivo en un directorio de sistema de archivos. |
Clase filesystem_error |
Clase base para excepciones que se producen para notificar un desbordamiento de sistema de bajo nivel. |
Clase path |
Define una clase que almacena un objeto de tipo de plantilla String adecuado para su uso como nombre de archivo. |
Clase recursive_directory_iterator |
Describe un iterador de entrada que establece una secuencia por los nombres de archivo en un directorio de sistema de archivos. El iterador también puede descender a subdirectorios. |
Clase file_status |
Ajusta un file_type. |
Estructuras
| Nombre | Descripción |
|---|---|
Estructura space_info |
Contiene información sobre un volumen. |
Functions
Funciones <filesystem>
Operadores
Enumeraciones
| Nombre | Descripción |
|---|---|
copy_options |
Enumeración que se usa con copy_file y determina el comportamiento si ya existe un archivo de destino. |
directory_options |
Enumeración que especifica las opciones de los iteradores de directorio. |
file_type |
Enumeración de tipos de archivo. |
perm_options |
Enumera las opciones de la función permissions. |
perms |
Un tipo de máscara de bits que se usa para transmitir los permisos y las opciones de permisos. |
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de