[boost] Re: Any interest in cross platform memory mapped file management class?

From: Craig Henderson (cdm.henderson_at_[hidden])
Date: 2002-10-10 03:03:42

"Malte Starostik" <malte_at_[hidden]> wrote in message
news:200210092314.04466.malte_at_starostik.de...
> IIRC some compilers have problems with this. Might be safer to rename the
> namespace.

Simple enough to do. I wasn't aware this could be problematic. I used VC6 &
VC7 and both accepted it so I assumed others would :-)

>
> (POSIX case)
> >    #elif defined(BOOST_HAS_POSIX_MMAP)
> >         typedef int memmap_file;
> >         typedef int protection;
> >         typedef int flags_or_security;
> >         typedef int max_len;
> >         typedef int offset;
> please consider off_t (from sys/types.h) for max_len and offset on POSIX
as it
> allows for 64-bit use.

No problem, I'll change these - I'm no POSIX guru.

>
> >         typedef enum { readonly, readwrite } open_access;
> In some cases, writeonly access makes sense as well (e.g. shared memory)

This would need to be a POSIX only option as Win32 does not provide
write-only access AFAIK. It would also complicate the interface as the
pointer returned from get() would be write-only. I guess attempting to read
this pointer could be documented as an undefined behaviour, as we couldn't
actually prevent the user from doing it.

> >       public:
> >         memory_mapped_file();
> >         memory_mapped_file(memory_mapped_file::memmap_file &handle,
> open_access access);
> >         ~memory_mapped_file();
>
> >         bool map_readonly(memory_mapped_file::memmap_file &handle);
> >         bool map_readwrite(memory_mapped_file::memmap_file &handle);
> Maybe add these?:
> bool map_writeonly(memory_mapped_file::memmap_file &handle); // see above
> memorory_mapped_file(const std::string& file_name, open_access access);
> bool map_readonly(const std::string& file_name);
> bool map_readwrite(const std::string& file_name);
> bool map_writeonly(const std::string& file_name); // see above

I deliberately stayed away from these in the initial design, but just knew
someone would request them :-)  I wanted to keep the class as clean as
possible, and therefore decided to restrict it to managing the memory
mapping to an open file. IMO, adding the file open/close handling muddies
the interface for little gain. The interface changes to support file handle
management would be quite large, because of the number of flags and options
for the Win32 CreateFile(). Perhaps a file management class would be a good
addition to Boost, and then this class could use that:

// warning: partial interface pseudo code follows
namespace boost {
    template<...>
    class file   // bad name !
    {
      public:
        bool close(void);
        bool create(...);
        bool is_open(void) const;
        bool open_readonly(...);
        bool open_readwrite(...);

        bool create_temporary(...);     // no file path required
    };

    template <typename T>
    class memory_mapped_file
    {
        ...
        bool map_readonly(const ::boost::file &);
        bool map_readwrite(const ::boost::file &);
        ...
    };
} // namespace boost

>
> >         // this is exposed publicly for completeness, but is
> >         // unlikely to be used by the library user
> >         bool map(memory_mapped_file::memmap_file         &handle,
> >                  memory_mapped_file::protection          &prot,
> >                  memory_mapped_file::flags_or_security   &fos,
> >                  memory_mapped_file::max_len             &len,
> >                  memory_mapped_file::offset              &off);
> Yes, it's unhandy to use, maybe the ctors and map_XXX() could take an
offse
> (default 0) and length (default 0 == auto)?

Well the idea was that any portable code would have to use the
ctor/max_XXX() anyway as calling this map() will require knowledge of the
platform, and that is what the class is supposed to be avoiding! Default
values could be used, as you suggest, but personally I don't really see any
benefit here.

Also, note that there is no access to the error code stored internally! This
is just a failing on my part. Sorry !

Regards
-- Craig