My problem exactly !

So I think this is what I need. Just to prove once again that no good deed goes unpunished -

a) at a very minimum I want to add a boost copyright license and for that I would need your name which wasnn't on your post.

Steve Robb is my name. I've updated my profile so that it should hopefully now appear on these mails.

b) any chance of this getting "boostified" with a couple of tests an maybe a micro-review?.

Certainly can. I'm only capable of testing it with a few compilers though: VC++s 6, 7 and 7.1, and GCCs 2.95 and 3.2.

c) I notice that the type_traits already in the library are much - much more elaborate due to the variations in compilers. Any chance of this getting subjected to this kind of treatment?

Actually, this leads to an issue we've had with compile times. The sheer volume of code included in the Type Traits headers to support all compilers lead me to re-implement a significant proportion of them in a 'minimal' fashion. Our build times almost halved as a result. Obviously our traits code doesn't cover the same body of compilers that Boost supports, but perhaps a rethink of the structure of the Type Traits library may be in order. To take a typical example like <boost/type_traits/is_same.hpp>, which can be implemented in terms of partial specialisation in a few lines on the majority of common compilers, still causes 59 headers (on my current configuration) on VC7.1. From this point of view, I prefer Loki's system of having a 'reference' copy of the traits class which fully-compliant compilers are directed to, with non-compliant compilers having their own implementations in separate files. I'm sure this issue has been raised here already, but I think it's worth reiterating, as it can save many man hours of wasted time.