From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-01-25 00:49:34
On Sat, 15 Jan 2005 16:50:07 -0500
David Abrahams <dave_at_[hidden]> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk