[boost] Re: utf8_codecvt_facet location

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

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.

Robert Ramey

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
>> questions:
>>
>> 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.
>
> John.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost