Large file iostreams

Martin Sebor sebor@roguewave.com
Fri Sep 5 00:24:00 GMT 2003


Pétur Runólfsson wrote:

> Martin Sebor 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.
>>
>>Not really. Portable code just needs to make sure to zero it out
>>before passing it to codecvt. Footnote 226 in 22.2.1.5.2, p5 even
>>suggests how it should be done in the generic case -- by assigning
>>it stateT().
> 
> 
> That footnote says that it is "typically" stateT(). I assume that
> the qualification is to allow user-defined stateT that needs some
> other mechanism. It says nothing about the specific case of
> mbstate_t.

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."

> 
> 
>>Yes. And C says it must be zeroed out, e.g., by assigning it
>>the value of mbstate_t() or calling memset(0) on it.
> 
> 
> That is the initial state for use with the mbrtowc and friends.
> Nothing in the C++ standard says that codecvt must be implemented
> in terms of the C library (or even that it should support the
> same set of encodings), so it doesn't follow that the initial
> state must be the same.

Hmm. I have never thought of it that way, even though our own
implementation uses mbstate_t values that have nothing to do
with those used by the C library (we still use mbstate_t() to
denote the initial shift state).

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.

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. 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.

Martin




More information about the Libstdc++ mailing list