C++ чтение больших файлов в венде
Я юзаю напрямую ReadFile и она при файлах >4Gb меня еще не подводила.
Через CREATEFILE/READFILE ?
МОжно будет попробовать ... Но хотелось бы выслушать еще мнения.
МОжно будет попробовать ... Но хотелось бы выслушать еще мнения.
лол.
"родной system oriented" виндозовский LPTSTR CStdioFile :: ReadString(
Это MFC что ли?
ReadFile конечно.
- Macro: _LARGEFILE64_SOURCE
If you define this macro an additional set of function gets
available which enables to use on 32 bit systems to use files of
sizes beyond the usual limit of 2GB. This interface is not
available if the system does not support files that large. On
systems where the natural file size limit is greater than 2GB
(i.e., on 64 bit systems) the new functions are identical to the
replaced functions.
The new functionality is made available by a new set of types and
functions which replace existing. The names of these new objects
contain `64' to indicate the intention, e.g., `off_t' vs.
`off64_t' and `fseeko' vs. `fseeko64'.
This macro was introduced as part of the Large File Support
extension (LFS). It is a transition interface for the time 64 bit
offsets are not generally used (see `_FILE_OFFSET_BITS').
- Macro: _FILE_OFFSET_BITS
This macro lets decide which file system interface shall be used,
one replacing the other. While `_LARGEFILE64_SOURCE' makes the
64 bit interface available as an additional interface
`_FILE_OFFSET_BITS' allows to use the 64 bit interface to replace
the old interface.
If `_FILE_OFFSET_BITS' is undefined or if it is defined to the
value `32' nothing changes. The 32 bit interface is used and
types like `off_t' have a size of 32 bits on 32 bit systems.
If the macro is defined to the value `64' the large file interface
replaces the old interface. I.e., the functions are not made
available under different names as `_LARGEFILE64_SOURCE' does.
Instead the old function names now reference the new functions,
e.g., a call to `fseeko' now indeed calls `fseeko64'.
This macro should only be selected if the system provides
mechanisms for handling large files. On 64 bit systems this macro
has no effect since the `*64' functions are identical to the
normal functions.
нужно определить эти макросы при компиляции, тогда fopen заменится на fopen64 и смещение внутри файла будет 64битным.
_LARGEFILE64_SOURCEЯ ведь правильно понимаю, что эти макросы надо определить в том модуле, где у меня происходит чтение файлов?
Если так, то у меня не получилось. Я определил "#define _LARGEFILE64_SOURCE" в файле где идет чтение, до подключения любых библиотек, в результате "'fopen64': identifier not found"
Тогда я определил "#define _FILE_OFFSET_BITS 64" без замены функций fopen на fopen64, в результате программа скомпилировалась, но эффекта нет (т.е. опять читает мусор).
Похоже завтра попробую ReadFile
неправильно
эти макросы надо определить в компиляции всего проекта. не в файлах надо прописывать, а в свойствах проекта, чтобы это подставилось в строчку компиляции.
эти макросы надо определить в компиляции всего проекта. не в файлах надо прописывать, а в свойствах проекта, чтобы это подставилось в строчку компиляции.
Это где? Полазил в свойствах проекта, незнаю, не нашел места куда бы вставить #define.
Можешь точно сказать, VS2003, спасибо!
Можешь точно сказать, VS2003, спасибо!
#defineэтого там точно не будет
там нужно будет прописатьравенство типа такого:
_FILE_OFFSET_BITS=64
не знаю где, но явно где-то в опциях компилятора
вместо A, B, C введи свои макросы:
_LARGEFILE64_SOURCE, _FILE_OFFSET_BITS=64
BotWi, Horror спасибо!
Правда не помогло, fopen64 по прежнему identifier not found, зато теперь знаю где надо прописывать.
Правда не помогло, fopen64 по прежнему identifier not found, зато теперь знаю где надо прописывать
.эх =\
fopen64 - это из цигвина что-то
эх..так под виндой не заведется это дело.
в виндовой компиляторе нету этих макросов =\
я помню под юнихами пользовал эти макросы.
в виндовой компиляторе нету этих макросов =\
я помню под юнихами пользовал эти макросы.
почему не заведется, определяй dllimport fopen64 или через LoadLibrary/GetProcAddress грузи
где реализована fopen64 ?
о какой длл речь?
о какой длл речь?
cygwin1.dll
почему-то у меня сомнения, что такая программа заработает.
ты так пробовал?
прогу ведь надо скомпилировать. а у нее будет набор функций пересекаться. как будет осуществляться работа с этим файлом (fscanf и тд)? через цигвин библиотеку?
ты так пробовал?
прогу ведь надо скомпилировать. а у нее будет набор функций пересекаться. как будет осуществляться работа с этим файлом (fscanf и тд)? через цигвин библиотеку?
У меня возникло подозрение что это чтото хитрое, когда не нашел fopen64 в мсдн
Вобщем сделал через CreateFile / ReadFile пока вроде работает
Вобщем сделал через CreateFile / ReadFile пока вроде работает
люди, откуда вы такие большие файлы берете? 8-0
Образы DVD, HDTV-фильмы, например.
банальные дампы результатов измерений с токомака
расскажи для чего ты делаешь fopen для DVD ? $)
Тебе правда интересно?
да, конечно
Лично я не делаю fopen для образов DVD, а использую CreateFile
с какой целью ты делаешь CreateFile для DVD ?
Последний раз я делал это с целью хэширования.
а круто
надо будет на досуге тоже похешировать
надо будет на досуге тоже похешировать
Оставить комментарий
vertyal17
Вобщем впервые столкнулся с такой проблемой, возникает с файлами размером >7GB (всмысле с такими файлами возникает точно, но возможно что предел может и 2 и 4 гб). НАчиная с некоторого момента функция fgets начинает читать какойто мусор, которого нет в исходном файле.Система WinXP , Visual CPP 6. SE чтение файла функцией FILE * = fopen ...
Вобщем я подумал что проблема в старом досовской fopen, и перешел на "родной system oriented" виндозовский LPTSTR CStdioFile :: ReadString(LPTSTR lpsz, UINT nMax ). Блин таже фигня.
Подумал что это VS плохой, и перешел на VS2003 с использованием CStdioFile. И опять таже фигня.
Прошу помощи. Какой правильный метод борьбы?