#### Archived

This topic is now archived and is closed to further replies.

# File I/O Functions

This topic is 5671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi! I was just wondering whether to use or not the Win32 functions that deal with files, such as CreateFile, DeleteFile, etc. What´s the difference between those functions and the C or C++ functions? Thanks!!

##### Share on other sites
The Win32 functions are likely to give you more control and to be marginally faster. However they are obviously not standard and won''t work on other platforms.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

##### Share on other sites
i read that the windows versions can be faster.

such as using file mapping instead of reading a file chunk by chunk. as i know it, native stdio and iostream dont have file mapping.

Its my duty, to please that booty ! - John Shaft

##### Share on other sites
Thanks for your posts! I´m not very interested in portability right now, so I think I´ll use the win32 functions. Thanks again!

##### Share on other sites
Here''s the real funny part:

Microsoft''s implementation of the C/C++ runtime library just encapsulates those functions.

so when you call:
FILE* f = fopen("filename.txt","a");

this is what actually gets called (fopen -> _tsopen -> _tsopen_lk):

  // from function _tsopen_lk (vc7/crt/src/open.c)#ifdef _MT        *punlock_flag = 1;        *pfh = fh;#endif  /* _MT */        /*         * try to open/create the file         */        if ( (osfh = CreateFile( (LPTSTR)path,                                 fileaccess,                                 fileshare,                                 &SecurityAttributes,                                 filecreate,                                 fileattrib,                                 NULL ))             == (HANDLE)(-1) )        {            /*             * OS call to open/create file failed! map the error, release             * the lock, and return -1. note that it''s not necessary to             * call _free_osfhnd (it hasn''t been used yet).             */            _dosmaperr(GetLastError());     /* map error */            return -1;                      /* return error to caller */        }

##### Share on other sites
quote:
Original post by daerid
Here''s the real funny part:

Microsoft''s implementation of the C/C++ runtime library just encapsulates those functions.

It''s not surprising that the implementation of the fopen() function involves CreateFile() - that''s the native Win32 file-opening function, after all. But it does not JUST call CreateFile(). There''s a fair amount of other code involved, mainly for taking care of the underlying stream mechanisms (like allocating memory for stream buffers). The same is true for fread()/fwrite()/fscanf() etc.

Files are normally buffered by the OS anyway, so you can gain some performance by avoiding this extra buffering layer. this potential performance advantage does not necessarily justify using the native functions; the C/C++ standard I/O mechanisms are highly portable and convenient.

##### Share on other sites
The bottleheck in IO is the IO itself - for disk IO it''s the access time. But normal IO functions are blocking, which means you can''t do anything while you''re waiting for that data.
If you use asyncronous IO, then you can process the last chunk of data while waiting for the next.

The fastest, easiest way is to use NT''s memory-mapped files. The kernel maps memory pages for the file to consume, and pages it in. You can also use overlapped IO and/or completion ports; they are more complicated, but they work for sockets as well (completion ports are 2k/XP only, overlapped IO works on 9x & NT4).

##### Share on other sites
In addition to memory mapped files look in to using a single large resource file. The memory mapping does some pretty cool caching \ read ahead. By using a zip file(no compression) and memory mapped files I''ve seen IO time drop to a 1/3 of what it was originally. Most of the files I load(textures etc) don''t even show up as a single milliseond in my profiler. I now spen more time processing my files in memory than loading them from disk.

So I''m off to simplify my ''in memory'' data processing(hence the other thread re memcpy & vector''s).

HTH

Chris Brodie
http:\\fourth.flipcode.com