Large file iostreams

[Pétur Runólfsson]

Martin Sebor wrote:
> Pétur Runólfsson wrote:
> >>>But it is never specified what is meant by "initialized".
> >>>I agree that this seems to be a real problem when using codecvt
> >>>directly.
> 
> But the only codecvt specializations are on mbstate_t. User
> defined stateT objects can only be passed to a user-defined
> specialization of codecvt, so I don't see how it could be
> a problem "when using codecvt directly."

I meant that this can only be a problem when codecvt members are
called from user code. Even if it was intended that the initial
state of mbstate_t should be unspecified (and I don't think it
was), this would not be a problem for library implementors,
since they could decide what the initial state should be and
use that.

> I think that the intent (Nathan could clarify this) must have
> been that C++ codecvt be (possible to be) implemented in terms
> of the C multibyte functions. Otherwise I don't see why even
> specify mbstate_t in C++ locale and not some completely
> unrelated state type.

I agree.

> But I see what you're getting at and agree that if the C++
> standard expects the same mbstate_t semantics as the C library
> it should say so.

Yes.

> I think the problem is that the whole locale
> section is written in overly generic terms even though the only
> types that most of the spec is entirely meaningful for are char,
> wchar_t and mbstate_t.

But the standard also specifies how used-defined specializations
must behave, see 17.4.3.1. Still, it is often hard to see which
parts of clause 22 are generic requirements, which parts are
requirements for the "required instantiations" and which parts
only apply to the "C" locale.

Regards,
Petur