From: Robert Ramey (ramey_at_[hidden])
Date: 2005-02-28 11:16:50
I can envision this coming up from time to time in the future. In fact, I
would expect that there are few other components in different places. The
issue came up here because it has compiled code. I don't know if this is
I think the current situation is adequate so I'm inclined not to mess with
it for now. However, I do believe that the directory for these things
should accomodate library pages and tests as should all boost libraries.
The library page for the utf8_codecvt_facet is currently in the
serialization library from which I would like to move it. The serialization
library currently has a test of this facet (I think the program options
library does as well). This is sort of OK, but I would like to see a more
logical home for it. If this were done, the serialization library would be
a little bit smaller which would be a good think.
I think we tried to get a fast track review of this at one time, but the
discussion metasisized into unicode conversion and was nitpicked to death -
so here we are.
John Maddock wrote:
>> I've made changes so that the serialization library uses the
>> utf8_codecvt_facet in boost/detail. Now I have a couple of
>> a) Where should the documentation page be moved to? I would expect
>> that there should be:
>> boost/libs/detail/codecvt/doc - but its not there
>> b) Where should the test be moved to? Right now I'm running the
>> test as part of the serialization libray. But I would be happy it
>> moved to somewhere else.
>> Looking at what we do to import the same code module under different
>> namespaces makes me think we would have been better off just getting
>> it officially into boost. The current system seems adequate - but
>> its a little
>> cumbersome and different than all the other boost libraries - so its
>> one more thing to figure out and keep track of for someone who wants
>> to use it somewhere else.
> IMO it's an ideal candidate for a fast track review, currently it's
> in Boost "via the back door" as a shared implementation detail, but
> if two or more libraries are already using it then that's probably a
> good reason to promote it to a full library of some sort.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk