Subject: Re: [boost] utf8_codecvt facet - volunteer opportuntiy
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-01-03 11:11:20
On Mon, Dec 24, 2012 at 5:53 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Our implementation for a codecvt facet internal wide char to/from utf8
> format requires some maintainence.
> We have our own implementation since 2001. Since then, the standard libary
> has come to specify some implementations and some libraries have implemented
> some or all of this aspect of the standard library. I've come to believe
> that we should:
> a) tweak our code to use the standard library implementations if they exist.
> b) tweak our code to use the names of the standard library implementation
> b) tweak our build so that our version replaces the the standard library
> when and only when there is no standard implemenation available.
> This seemingly simple task is complicated by the following circumstances.
> a) The relationshp between UCS and Unicode is pretty confusing.
> b) The iterface for codecvt is confusing.
> c) a number of standard library implementations have non-conforming
> codecvt interface.
> d) a number of standard library implementations don't have any
> codecvt header at all. This is not a problem for our current
> implementation because we never import it.
e) VC++ 2012 actually has the header <codecvt> functions, but puts
them in separate headers that live in a "cvt" sub-directory, along
with a great pile of codecvt facets, and some conversion functions
such as wstring_convert that the standard puts in <locale>. So you
have to write #include <cvt/wstring_convert> instead of #include
<locale> to get wstring_convert.
<aside>That's probably yet another example of how legally and/or
politically difficult it can be to modify the contents of an existing
So, yes, someone does need to address these issues.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk