[boost] Re: [python] type_id

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-25 09:27:08

Jody Hagins <jody-boost-011304_at_[hidden]> 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