Robert Ramey wrote:
Robert, would you want me to change serialization to include the file, too?
Just create the new place. I'll tweak my stuff to include it from the new spot and remove the utf8 stuff from my project.
1. Are there any objections?
I still have a couple of questions:
a) how do we insure that that if a program uses several libraries each of which in turn uses the common utf8 module, we don't get multiply defined symbols at
The "common" files will be included into a wrapper file (one for each library), with different namespaceses: namespace boost { namespace program_options { #include "../../libs/detail/utf8/utf8_codecvt.cpp"
b) Please compare your version and my version to make sure that the new version is the union of any changes. There are really annoying issues related to the namespaces where things like mbstate_t are found on different platforms. My version has been tested back to bcb 5.51 and I believe includes accomdations for all these platforms. Likely your version includes some differences to address issues that you've come accross. So I would like to see the the two versions "melded". I don't think this is hard as the differences if any should be very small.
Sure, I'll do my best.
c) This brings up the question of testing. I wrote a test which I would like to see incorporated in the normal testing routine. This has been indispensable in smoking out small incompatibilities between library versions. In many cases this is the only test that detects this stuff as serialization and program options are the only libraries that really use wide character i/o.
Where the test is? You mean utf8_codecvt_test which is part of serialization? Sure, it should be included. The more tests, the better.
d) I would like to see the manual page moved into the appropriate spot as well.
All this suggests its has all the features of a full blown library - with only one module. I also think its more than an implementation "detail". So I would like to see created boost/libs/utility/utf8/... and be sort of "official". There have been at least three recent proposals to make a more complete utf8 implementation. If any of these were to be completed and accepted into boost they could replace what's already in here. Making a libboost_utility would fix up the issue multiple definitions of the same module. It would also mean that utf8 isn't some weird special case that has different rules as to its usage compared to other boost libraries.
I think I'm not at liberty to bypass the regular rules for library acceptance. I'd rather add it to detail. Moving it to a different location is always possible later.
In effect, as a practical matter this module has been accepted into boost as part of two libraries. Ample opportunity has been available to object to its inclusion during the course of two reviews. It should be considered accepted until something better comes along. When that happens, it can replaced with the "next great thing"
Given that those parts are implementation details, I think nobody cares about them much.
2. Who does it? I can do it soon.
I'm fine with this. Create the new spot. I'll switch over to it after any dust settles.
Will do this on Tuesday. (Monday is a holiday here). - Volodya