Todo depende del sistema operativo y del sistema de ficheros. Hay sistemas de ficheros que no soportan ficheros de más de 2 GB o más de 4 GB... Esto implica que, aunque ftell() en el estándar POSIX devuelva long, es probable que sistemas que no cumplan el estándar 100% no devuelvan long (o ponga long pero en realidad usen int internamente, es imposible saber sin tener el código fuente del SO).
la funcion de la API, GetFileSizeEx, solo funcionara en sistemas windows, pero que funcion de libreria estandar me puede ayudar?Ya te digo que Windows no cumple los estándares, así que si programas para Windows, mejor olvídate de la portabilidad.
Entonces, si programo bajo Linux, me puedo olvidar de una funcion que me diga el tamaño de un archivo de 8 GB? o su sistema de archivos(de Linux) no soporta archvos de 8 GB?Cita de: "maxstepin"la funcion de la API, GetFileSizeEx, solo funcionara en sistemas windows, pero que funcion de libreria estandar me puede ayudar?Ya te digo que Windows no cumple los estándares, así que si programas para Windows, mejor olvídate de la portabilidad.
si programo bajo Linux, me puedo olvidar de una funcion que me diga el tamaño de un archivo de 8 GB?Linux sí conforma más a POSIX (aunque no totalmente), así que ftell() debería funcionar bien.
La unica solucion bajo windows es usar getfilesizeex? no hay nada mas?Pues va a ser que no. Quejas al de la foto.
ese soy yo. a que soy guapo?Cita de: "maxstepin"La unica solucion bajo windows es usar getfilesizeex? no hay nada mas?Pues va a ser que no. Quejas al de la foto.
A ver, que yo sepa en x86 un long ocupa 4 bytes¿Sí? Que yo sepa un int ocupa 4 bytes (modo protegido) :huh:
¿Sí? Que yo sepa un int ocupa 4 bytes (modo protegido) :huh:
TRANSITIONAL DESCRIPTION (NOW DEPRECATED)Eso es en Darwin, pero no me estrañaria que otros sistemas operativos digan lo mismo, es mas, Open Group no lo documenta, asi que no es POSIX.
The fstat64, lstat64 and stat64 routines are equivalent to their corre-
sponding non-64-suffixed routine, when 64-bit inodes are in effect. They
were added before there was support for the symbol variants, and so are
now deprecated. Instead of using these, set the _DARWIN_USE_64_BIT_INODE
macro before including header files to force 64-bit inode support.
yo lo que suelo hacer para portabilidad es usar el patrón factory y crear una clase para win32 y otra para unix.
entonces simplemente uso la api en uno y la stat en el otro.
¿Pero stat no es capaz de devolver el tamaño de un archivo de mas de 4GB, verdad?Si estas en una maquina de 64 bits, si que puede... en 32 bits se supone que tambien, no se si en el Glibc actual arreglaron el problema, pero aqui lo documentan muy bien. (http://www.suse.de/~aj/linux_lfs.html)
Si no hay funcion standard entonces da lo mismo usar un servicio de un S.O. en particular (ademas que estos suelen ser mas potentes y con #ifdef se soluciona cualquier problema de portabilidad del codigo).Me explique mal :nosweat:
Si estas en una maquina de 64 bits, si que puede... en 32 bits se supone que tambien, no se si en el Glibc actual arreglaron el problema, pero aqui lo documentan muy bien. (http://www.suse.de/~aj/linux_lfs.html)
Me explique mal :nosweat:
stat (http://www.opengroup.org/onlinepubs/000095399/functions/stat.html) si es estandar, pero stat64 no lo es.
Exacto, no hay funcion standard que te sirva para obtener el tamaño de un archivo de mas de 4GB en un Windows o GNULinux de 32 bits, de una manera u otra tenes que recurrir a funciones no standard (VC++ soporta _stat64 por cierto, con guion bajo por no ser standard).Pero el fichero <sys/stat.h> existe en la carpeta include de Mingw, quiero decir que no me lo he bajado de ningun sitio. SI viene de serie con el compilador, no es una libreria estandar?
¿Que IDE usas?Codeblocks, y de compilador Mingw TDM's GCC/mingw32 Builds, de la siguiente pagina: