portable fmemopen

[yancheng.cheok@gmail.com]

i have a vendor function, which need to take into FILE* as function
arguement.

vendor_function _read_and_proce ss(FILE* f)

however, by reading from disk file during run-time, we get performance
penalty.

hence, instead of having f pointing to a disk file, we would like to
have f mapped to a memory location.

fmemopen is what we are looking for. however, since we are developing
is MSVC windows platform, i was wondering whether there is any portable
library to do so?

thank you.

[santosh]

Re: portable fmemopen

yancheng.cheok@ gmail.com wrote:

i have a vendor function, which need to take into FILE* as function
arguement.
>
vendor_function _read_and_proce ss(FILE* f)
>
however, by reading from disk file during run-time, we get performance
penalty.

Who says that f has to control a disk file? Is it under your control or
not?

hence, instead of having f pointing to a disk file, we would like to
have f mapped to a memory location.

f is just a pointer to an object of type FILE. That too, despite it's
name, is probably a simple structure object. f will control a disk
file, only if you make it do so by a call to fopen() or similar. If you
want to map that disk file, whatever it is, to memory then memory
mapped files is the first idea.

fmemopen is what we are looking for. however, since we are developing
is MSVC windows platform, i was wondering whether there is any portable
library to do so?

I suspect, memory mapping the file using the native Windows API would
be sufficient unless the requirements are special. Even then you'll not
be able to avoid the overall penalty incurred in reading it ina
piecemeal fashion from the hard disk.

Anyway, standard C has no provisions for what you're seeking. Ask in a
Microsoft newsgroup like comp.os.ms-windows.program ming.

[Malcolm]

Re: portable fmemopen




<yancheng.cheok @gmail.comwrote in message
news:1163618273 .541831.8110@m7 g2000cwm.google groups.com...

>i have a vendor function, which need to take into FILE* as function
arguement.
>
vendor_function _read_and_proce ss(FILE* f)
>
however, by reading from disk file during run-time, we get performance
penalty.
>
hence, instead of having f pointing to a disk file, we would like to
have f mapped to a memory location.
>
fmemopen is what we are looking for. however, since we are developing
is MSVC windows platform, i was wondering whether there is any portable
library to do so?
>

Sadly, this is a major weakness in the standard. There is no way of creating
memory files or indeed and user-defined type of stream.
--

https://www.personal.leeds.ac.uk/~bgy1mm

freeware games to download.

[Keith Thompson]

Re: portable fmemopen

"Malcolm" <regniztar@btin ternet.comwrite s:

<yancheng.cheok @gmail.comwrote in message
news:1163618273 .541831.8110@m7 g2000cwm.google groups.com...

[...]

>fmemopen is what we are looking for. however, since we are developing
>is MSVC windows platform, i was wondering whether there is any portable
>library to do so?
>>

Sadly, this is a major weakness in the standard. There is no way of creating
memory files or indeed and user-defined type of stream.

There's no standard way of specifying that a given file exists in
memory. But then again, there's no standard way of specifying that a
given file exists on disk. The interpretation of a file name is
entirely system-specific.

An implementation could easily specify a particular form of file name
that refers to in-memory files; then all the machinery that normally
deals with disk files should just work. I wonder why more
implementations don't do this.

(Some implementations can implement in-memory file systems, but
there's no good way to tell that a given file is on such a file
system. For example, <OT>"/tmp" might be implemented as swapfs on one
system, as a physical disk on another, and even as a remote
NFS-mounted filesystem on yet another, with all three systems running
the same version of the same operating system.</OT>)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.