Jody Hagins <jody-boost-011304@atdesk.com> writes:
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...
I don't think we should be glomming any new stuff into utility, and we definitely shouldn't build a monolithic library for all the utility code. I believe typeid makes sense as a separate library.
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.
#4 sounds good to me.
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?
Technically, DLL would have to remain a not-officially-documented implementation detail of typeid DLL is separately fast-track reviewed, unless we are somehow going to fast-track review them together.
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...
i'm-from-new-jersey-we-like-sweet-corn-ly y'rs, -- Dave Abrahams Boost Consulting www.boost-consulting.com