[boost] Re: IOStream mmap too restrictive?

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-02 09:50:47

"Jonathan Graehl" <jonathan_at_[hidden]> wrote in message
news:41367DC5.5050202_at_graehl.org...

> Since ftruncate isn't portable, it seems something like this (warning:
> untested) would be appropriate for boost::filesystem (perhaps taking a
> path object as an argument instead of a string - and shouldn't the Boost
> IO library do the same?)

I considered using fs::path arguments for the file-based components in the
iostreams library, but I decided against it (tentatively) because I didn't want
to create a dependency between the libraries and because it made the components
slightly harder to use (esp. in the regression tests.)

> #ifdef _WIN32
> #include <io.h>
> #else
> #include <unistd.h>
> #endif
>
> bool create_file(const std::string& path,std::size_t size) {
> #ifdef _WIN32
>     int fh=::_open(path.c_str(),_O_CREAT|_O_SHORT_LIVED);
>     if (fh == -1)
>         return false;
>     if (::_chsize(fh,size) == -1)
>         return false;
>     return ::_close(fh) != -1;
> #else
>     return ::truncate(path.c_str(),size) != -1;
> #endif
> }

For portability it's best to stick to the win32 API. I managed to implement
relatively portable file descriptor resources, but discovered that there is
enormous variation in the low-level i/o functions provided by the
runtime-libraries of different vendors.

> I guess there's enough work left to be done for a "proper" Windows/POSIX
> mmap wrapper that the IO library shouldn't attempt to promote it yet.

Yeah, I'd like the discussion to focus on the architecture of the iostreams
extension framework and is implementation.

Jonathan