|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2004-12-08 11:58:05
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:200412081123.32817.ghost_at_cs.msu.su...
> The problem with compiled library is that users will have to
> know that in addition of -lboost_program_options they'll have to add
> -lboost_utf8, which is inconvenience. I've mentioned this in
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/106047/
>
> The proposed course of action is documented in:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/106122
> > 1. put new header to boost/detail
> > 2. put new source to libs/detail/utf
> > 3. #include new source in program_options.
> > Objections? As I understood, Robert does not mind to have this issue
handed to me.
No objection at all.
> > 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
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.
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.
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.
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"
> 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.
> Robert, what do you think?
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk