[boost] Boost policy on relying on std library implementation defined behaviour

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-24 13:14:05

Hi All,

Is there a reason to avoid providing a uniform interface to
implementation-defined standard library features?

One of the most often heard complaints about the standard iostreams library is
that there is no portable way to seek within a file stream using large (64-bit)
offsets.

Simplifying a bit, the standard library provides functions for seeking within a
stream using

- an offset of type streamoff, which may be 64-bits but is sometimes smaller, or
- a position indicator of type streampos (usually fpos<mbstate_t>), a
non-integral implementation defined type, with implicit conversions to and from
streamoff. (streampos also stores a code conversion state, but I'm ignoring
this)

There are platforms where streamoff is inadequate to express an arbitrary seek
offset, and where streampos is adequate, but only if implementation defined
functionality is used. (There might be cases where neither type is adequate, but
I'm ignoring this)

I would like to implement functions which provide conversions between a large
integral type and streampos. This will allow most uses of streampos to be
hidden, with library users specifying integral types most of the time.

The alternative would be:
1. provide additional concepts which require user defined filters and devices to
implement functions involving streampos, AND
2. force users to deal with streampos directly, relying whatever guarantees are
provided by their standard libraries.

Point 1. requires complicating the iostreams library interface. Point 2. forces
users to implement functions which could instead have been implemented just once
by the iostreams library.

What do people think?

Jonathan