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