[boost] Re: Boost policy on relying on stdlibraryimplementationdefined behaviour

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-03-26 09:26:46

"Jonathan Turkanis" <technews_at_[hidden]> wrote in message 
news:d22hfp$7e9$1_at_sea.gmane.org...

> Two possibilities I can think of are as follows (I'm writing this off the 
> top of
> my head -- I'll need to give it more thought):
>
> 1. require streamoff (and the various member types, such as
> char_traits<>::off_type which have the same requirements as streamoff) to
> satisfying whatever requirements you would impose on the second parameter 
> of
> fseeko.
>
> 2. Change the legend to Table 88 (27.4.3.2/1) so that
>  - instead of referring to type streamoff, "O" refers to an integral type
> satisfying whatever requirements you would impose on the second parameter 
> of
> fseeko.
>  - "o" refers to a value of type "O"
>
> Option 1 is more straightforward, but could require some standard 
> libraries
> (notably Dinkumware) to change the size of their streamoff type even 
> though
> their streampos already provides adequate large-file support. Standard 
> libraries
> which already provide a large streamoff would need no change.
>
> Option 2 would allow standard libraries which provide a small streamoff 
> but a
> streampos capable of storing large values to conform by providing a 
> streampos
> constructor callable with a single parameter of type "O" and by replacing 
> the
> conversion to streamoff with a conversion to "O".
>
> How do these strike you?

I started to answer your question as asked, but then realized it isn't my 
opinion that counts, but rather the LWG's collective opinion, which will be 
heavily influenced by the implementers. So maybe what we ought to do over 
the next two weeks is to build up a list of questions, then ask the LWG in 
Lillehammer for their preferences.

Action plan for the next couple of days is to read chapter 27, and try to 
identify as many issues as possible.

--Beman