Boost logo

Boost :

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-14 21:13:35

On Wed, Jan 14, 2015 at 2:58 PM, John Maddock <boost.regex_at_[hidden]> 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.
> 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.

Every one of those is a big win.

> 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.
> 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 ;)

Those don't seem like showstoppers, either individually or in
aggregate. Careful testing, and social engineering like announcing the
1.58 beta more widely than usually will help, too.

> 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?


The potential risks seem minor compared to the known gains.


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