portable fmemopen

Discussion in 'C++' started by yancheng.cheok@gmail.com, Nov 15, 2006.

  1. Guest

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

    vendor_function_read_and_process(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.
    , Nov 15, 2006
    #1
    1. Advertising

  2. santosh Guest

    wrote:
    > i have a vendor function, which need to take into FILE* as function
    > arguement.
    >
    > vendor_function_read_and_process(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.programming.
    santosh, Nov 15, 2006
    #2
    1. Advertising

  3. Malcolm Guest

    <> wrote in message
    news:...
    >i have a vendor function, which need to take into FILE* as function
    > arguement.
    >
    > vendor_function_read_and_process(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.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
    Malcolm, Nov 15, 2006
    #3
  4. "Malcolm" <> writes:
    > <> wrote in message
    > news:...

    [...]
    >> 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_Keith) <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.
    Keith Thompson, Nov 15, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eli Bendersky
    Replies:
    1
    Views:
    1,162
    Mike Treseler
    Mar 1, 2006
  2. Markus Dehmann
    Replies:
    14
    Views:
    921
    Irrwahn Grausewitz
    Jun 28, 2004
  3. Markus Dehmann

    fmemopen: portable version?

    Markus Dehmann, Jul 12, 2004, in forum: C Programming
    Replies:
    5
    Views:
    513
    Dave Thompson
    Jul 19, 2004
  4. portable fmemopen

    , Nov 15, 2006, in forum: C Programming
    Replies:
    3
    Views:
    719
    Keith Thompson
    Nov 15, 2006
  5. Pasquale Minervini

    Strange problem with fmemopen() and fgetwc()

    Pasquale Minervini, Apr 13, 2009, in forum: C Programming
    Replies:
    3
    Views:
    583
    Antoninus Twink
    Apr 15, 2009
Loading...

Share This Page