|
Boost : |
From: SRobb_at_[hidden]
Date: 2004-07-08 06:35:43
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk