
On Sat, 15 Jan 2005 16:50:07 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The way these things are handled is as follows: if another Boost library wants to use facilities that are an implementation detail of an existing Boost library, they are moved into boost/detail by the author of the former library. If someone wants to make the functionality available to users, that person moves it into namespace boost, documents it, and writes tests. Then the library goes through a fast-track review process.
I have done this, but there is a compilation unit, to do the "pretty" printing. Thus, I see several options, and would like some input. Currently, there is no Boost.Utility compiled library, but I think the type_id stuff fits into Utility better than anything else. It does not seem to be its own library since it is providing utility access and workaround for the typeid facility. If there were a libutility, then I'd just add it there... Also, Dave suggested that it be moved into a detail namespace, but I think it is useful as a general library, not an implementaion detail (which I believe is the purpose of the detail namespace). So, I'd like to have it available as boost::type_id. 1. Move the code that is currently compiled into a library into a .hpp file, thus preventing the need for a compiled library. 2. Start a "utility" library, with this as the first entry. 3. Start a "catchall/common" library, with this as the first entry. 4. Provide a separate "type_id" library with this one entry. In the process of writing the tests for the type_id code, I had to do some shared library work. Since there is nothing in boost for this already, I also wrote a DLL library (which I think *should* be it's own library -- though it does not require an explicit compiled library -- it is all in headers). Would the DLL library be on the same fast-track for type_id, or would we need to first wait for the DLL to get type_id done? FWIW, everyone should try to go through something small like this, if for no other reason than to appreciate the vast amount of effort involved in the entire process... especially learning the build environment, getting code to work on non-conforming compilers, and writing reasonable tests. Even so, when I present the modified code, I have issues myself to raise (as if that were not obvious by now ;-). Anyway, thanks to everyone for much patience, and very little scorn...