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

From: Craig Henderson (cdm.henderson_at_[hidden])
Date: 2002-10-13 16:59:21

Hi Malte,
I have added an initial implementation to the Boost Sandbox. The header is
memmap.hpp in the main boost directory, with the platform dependent headers
in boost/memmap. The doc and test program is in libs/memmap.

I'd appreciate any feedback - improvements, changes or discussion ;-)

Regards,
Craig

"Malte Starostik" <malte_at_[hidden]> wrote in message
news:200210121912.22925.malte_at_starostik.de...
> On Thursday 10 October 2002 10:03, Craig Henderson wrote:
> > > >         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.
> I thought I used writeonly on Win32, maybe misremembered. If it's POSIX
only
> and since C++ doesn't provide for it (duh, I should really have thought of
> this) it's probably not worth it.
>
> > > 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
> Fully agreed.
>
> Regards,
> -Malte
>
> --
> #!/usr/bin/perl
> $t='char|short|int|long|void';%m=qw(U "unsigned\040$3" W
"w$3_t");while(<>)
> {/#define
UNICODE/and$m{T}=$m{W};s/\b(LP)?([UWT])?($t)\b/lc(eval$m{$2}||$3)
> .($1?'*':'')/gei;print;}print"/* Cleaned by Malte's WinAPI sanitizer
*/\n";
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>