Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-01-14 20:05:54
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
> https://github.com/boostorg/type_traits/tree/Version2 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.
> 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 ;)
> 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.
Testing gcc on Windows 7 with mingw and mingw64:
Running type_traits tests passed with msvc-8.0, msvc-9.0, gcc-4.4.0,
gcc-4.5.0, gcc-4.5.2, and gcc-4.9.2.
Failed with gcc-4.3.0 with:
====== BEGIN OUTPUT ======
has_nothrow_assign_test.cpp:204: The expression:
"::boost::has_nothrow_assign<nothrow_construct_UDT>::value" had an
invalid value (found 1, expected 0)"
In type_traits with gcc versions below 4 there are lots of failures of
the order of:
../../../boost/type_traits/is_virtual_base_of.hpp: In instantiation of
from `boost::detail::is_virtual_base_of_impl<Base, Derived,
boost::integral_constant<bool, true> >'
from `boost::detail::is_virtual_base_of_impl2<Base, Derived>'
from `boost::is_virtual_base_of<Base, Derived>'"
etc. Of course I can't imagine anyone still using those versions.
The function_types library depends on some type_traits implementation
which is not in Version2, and tti uses function_types etc so tti fails.
> * 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...
Where are the compiler requirements for type_traits mentioned ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk