on Thu Jan 01 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-)
OK - here is my example.
The serialization library includes and depends upon another component which is logically separate: This is extended_typeinfo. It extends the standard typeinfo in order permit one to use a portable string as a universal identifier. So, given this, one can access the static extended typeinfo record, And given this one can request the construction of object of the corresponding type. This is effectively a (mostly) portable C++ system similiar to COM / CORBA and is used and tested as part of the serialization library.
Now suppose I decide - this is really a new library whose functionality I would like to see included in boost. Can I just promote this to that status without a review of some sort? How about BOOST_STATIC_WARNING? Can I promote this as well?
You can promote them to "exposed and supported features/sub-libraries of Boost.Serialization" but not to top-level Boost libraries. -- Dave Abrahams BoostPro Computing http://www.boostpro.com