type traits, reflection, and whatnot

[Phil Edwards]

Some peudorandom thoughts:

Gaby's arguments about creating a branch for C++ reflection have convinced
me.  His thoughts on waiting another week or so before creating the branch
also sound good to me.  (Thoughts from anyone else?)

In the informal discussion the Gaby mentioned (@Santa Cruz), were there
any kinds of reflection /not/ covered by N1345 that y'all were pondering?


As far as N1345 goes, I'm happy with nearly everything in the proposal as
it exists in published HTML form.  (I don't have access to any updates
that might have taken place since then, e.g., its wiki page.)  I agree
with Howard Hinnant's comment (page 4 or so) that is_floating_point would
be a better name than the published proposal's is_float.

As for the "mechanism of compiler support," I think option 4 would suit us
best:  note when a particular template class is to be instantiated, and have
the compiler fill in the blanks directly.  I'm thinking of something along
the lines of rtti.c, where we already have tree nodes for the type_info
class, but require the user to include <typeinfo> before allowing its use.


Several months ago in private email, David Abrahams pointed out to me
that the Boost type_traits library already does nearly everything called
for by N1345, and does it in user space.  Only a few templates need
compiler support directly.  (And they're specified in the proposal.)
If we were to add the appropriate hooks into the Boost config header,
their entire implementation would work properly for GCC.  We could then,
as he further suggested, remove all the hooks for other compilers; this is
the same thing that we did for the SGI STL and for the Boost concept checks.

I feel that it would be easier and more maintainable to implement the bulk
of N1345 in library code, and only build special knowledge into the compiler
of the few templates which need it.  I also feel it would be cleaner to
write the library headers rom scratch rather than importing the headers
from Boost.  (I've been looking at their implementation, and while I think
it's really cool, I wouldn't want to try and track it for our own usage.)


That's all the random gibberish I can think of for now.

Right now v3 has two different type traits schemes at work in the library.
I've been wanting to clean them up for a long time but haven't really had
a clue how.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002