[boost] [Iostreams] Patches in 1.34?

From: Sylvester-Bradley, Gareth (Gareth.Sylvester-Bradley_at_[hidden])
Date: 2006-02-21 07:50:10

Hello,

Boost.Iostreams is definitely making my life a lot easier!

However I do hope a number of patches can be included in time for 1.34.

There have been a number of patches proposed on the list, such as this patch
for a file_descriptor openmode bug on Windows:
http://lists.boost.org/Archives/boost/2006/01/99425.php.

Here are a number of other issues it would be great to fix.

1. Support for binary openmode in file_descriptor

Extend the above patch to incorporate selecting O_BINARY for
ios_base::binary. Or is this not necessary even on Windows?

2. file_descriptor_source and file_descriptor_sink aren't Seekable

This is because they have the wrong category. I believe this is an oversight
(their base, file_descriptor is Seekable) and very easy to fix.

3. A significant performance problem for streams on Seekable Indirect
Devices

This is due to the setg(0,0,0) in indirect_streambuf::seek_impl().

The real killer is that even tellg() causes the buffer to be reset. I have a
real application that makes many small istream::read() calls, each followed
by an istream::tellg(). This results in a huge number of redundant reads
from the underlying Device.

E.g. starting at the beginning of the stream, I call istream::read() for 4
bytes, which results (correctly) in a Device read of optimal_buffer_size
which is 64K.
Then I call tellg() which unfortunately clears the buffer. Then I read
another 4 bytes, which reads 64K from offset=4, resulting in 65532 bytes
being re-read. Etc.

I believe that relative seeks within the buffer need not cause the buffer to
be reset.

I.e. something like:

  if ( gptr() != 0
    && way == BOOST_IOS::cur && which == BOOST_IOS::in
    && eback() - gptr() <= off && off <= egptr() - gptr() )

should result in something like:

  {
    gbump( off );
    off = 0;

    // Really we don't want the involvement of the
    // Device at all, but at the moment, in order to
    // return the new position, we must ask the Device
    // for its current position again. Hopefully that's
    // cheap.

    const pos_type pos_at_egptr =
      obj().seek(0, BOOST_IOS::cur, BOOST_IOS::in, next_);

    return offset_to_position(
      position_to_offset( pos_at_egptr )
      - static_cast<stream_offset>(egptr() - gptr()) );
  }

... falling back to the existing behaviour in all other cases.

This patch works for me, but there may be situations that I haven't
encountered (combined input/output streams, the presence of code converters,
...) when this optimization would actually result in incorrect behaviour.
Can anybody comment?

4. (feature request) file_descriptor could support wide character filenames

One of the possible advantages I see to using file_descriptors rather than
std::fstream is that we could add wide-character filename support on
platforms that have a matching wopen(), _wopen(), or _wrtl_open() as well as
open(), _open() or _rtl_open().

This would mean the file_descriptor could have wstring constructor and
open() methods.

Neat or not?

Thanks,
Gareth

************************************************************************
The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s).  Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender.  The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies.  Sony email is for business use only.

This email and any response may be monitored by Sony to be in compliance with Sony’s global policies and standards