Re: [boost] Unicode and codecvt facets

Subject: Re: [boost] Unicode and codecvt facets
From: Eric MALENFANT (Eric.Malenfant_at_[hidden])
Date: 2010-07-06 10:30:18

De : Mathias Gaunard

> Le 05/07/2010 20:35, Artyom wrote:
> 
> > also you'll find may issues with it, it is
> > not suitable for it.
> 
> What kind of issues? Are you expecting many-to-many conversion to not
> work?

There *may* be issues, yes. The question is still unclear, IMO, and is summarized at the end of this post by Alberto Barbati, who once proposed a "Boost UTF" library of codecvt facets: http://lists.boost.org/Archives/boost/2003/01/41969.php. The DR Alberto refers to in this post is issue 393: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393, whose proposed resolution is applied in n3092. 

However, this seems to create a contradiction: The note coming from the resolution of issue 393 is there, but the footnote stating that this paragraph informally means that only 1 to N encodings are supported with basic_filebuf is there too. This is unfortunate considering that issue 393 was created to allow the use of "state" in order to support N to M encodings without violating the "one internal character at a time" rule.
 
Summing up: It seems clear that codecvt in itself can support N to M convertions, but it is unclear (to me, at least) whether it is usable with basic_filebuf.
 
> I only need facets if they can be used by an fstream to convert their
> data.
> There is no point in creating other types of facets if they're not used
> by the iostreams subsystem. The whole point of the exercise is to allow
> the iostreams subsystem to make use of my converters.

Indeed. And, considering the above, there may be a problem. However, even if it may not work with the standard fstream, there is still be a useful application area: Boost.IOStream's code_converter. (in fact, we currently use Alberto's proposed library that way).