SRobb@reflectionsinteractive.com writes:
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.
If so, and if your type traits are really doing as throrough a job on the compilers you *do* support, it should be possible for us to reorganize our own headers to achieve the same speedup. We do something like that with the MPL... but someone would have to be willing to do it ;-)
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.
You mean hours of build time? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com