Boost logo

Boost :

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-01-14 19:17:28

On 1/14/2015 2:58 PM, John Maddock wrote:
> I'm going to throw this out there to see what folks think:
> In a branch called "Version2", see
> is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the
> old one, but there's a pretty good selection to test.

How do I get this version in my local modular boost to test ? Won't it
conflict with the type_traits already there if I just clone it directly ?

> The main pros for this version are:
> 1) Zero dependencies other than Boost.Config.
> 2) No horrible macro-obfuscation - all "real code", making it easier to
> read and maintain.
> 3) Substantially reduced template instantiations where practical - often
> half as many as before.
> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined
> by the actual implementation variant when appropriate. There were also
> a lot of spurious #includes left over from old workarounds no longer used.
> The main cons:
> 1) I don't know what I've broken, but surely something, you can help by
> testing but I would guess we would never be 100% sure it's all right
> until it's out in the field. This is the main reason for avoiding this
> until now.
> 2) MPL interoperability should still work, but files which expect
> type_traits headers to have included mpl ones will be broken unless they
> explicitly include what they need.

Anyone who assumes header files will be included, rather then include
what's needed, for any C++ software deserves to be broken.

> 3) Current MPL inter-operability is fragile see
> 4) Function dispatching to an mpl::bool_ involves an (inline) function
> call where as the old inheritance scheme did not. This should mostly
> disappear once optimizations are turned on, but is still a potential
> issue for some folks I suspect.
> 5) I haven't got to the "difficult" headers like common_type.hpp yet.
> 6) Whatever I've forgotten ;)
> Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
> kind of "core" header.
> So... what I need from you kind folks is:
> * Is this the right way forward?
> * Can you test with your favourite compilers and compare with results
> for develop - So far I've tested with msvc-10,11,12,14 Intel 14,15,
> GCC-4.5.4...4.9.1, plus a reasonably recent clang.

I can test with some earlier versions of gcc as well as msvc-8 and
msvc-9 as soon as I get the branch.

> * If anyone would like to help converting further traits all help would
> be much appreciated.... Oh and the compiler requirements in the docs are
> all wildly out of date too...

Boost list run by bdawes at, gregod at, cpdaniel at, john at