Boost logo

Boost :

Subject: Re: [boost] New dependency report
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-06 18:20:23

Le 06/06/14 23:40, Peter Dimov a écrit :
> John Maddock wrote:
>> I'm tied of saying this.... but if mpl::bool_ and int_ were moved out
>> of MPL full, either to core, or to some mpl_core, then there's no
>> need to split type_traits anymore.
> The question is: what is the minimal conforming implementation of a
> type trait? Is it
> template<class T> struct something
> {
> bool const value = false;
> }
> or is it, instead,
> template<class T> struct something: mpl::false_
> {
> };
The answer as for the documentation
* for TypeTraits trais is

template <class T>
struct is_abstract : public /|true_type <>-or-false_type <>|/ {};

I interpret these are the ones on boost namesapce.

* for MPL traits is

       typename T1
     , typename T2
structless <>
     typedef/unspecified/ type;
Returns a true-valuedIntegral Constant <> ifT1 is less thanT2.

Here an integral constant has some constraints not satisfied by boost::integral_constant, as tag, next, prior.

I think that TypeTraits shouldn't require the MPL constraints. In order to be compatible with C++11 we should provide the same interface than std::integral_constant.

> For C++11, the answer to this question determines whether the std type
> traits are conforming type traits for us. In other words, whether
> "using std::is_pointer;" is a conforming implementation of
> boost::is_pointer.
> For C++03, the answer determines whether I can specialize a type trait
> for my type without including the header that defines mpl::true_ and
> mpl::false_.
Well, you could include a header that defines boost::true_type and
boost::false_type ;-)
Or you could define the traits defining every_thing integral_constant
> I prefer the first definition for reasons already stated. This doesn't
> mean however that going with the second, along with a lean and mean
> mpl::bool_, will not going to be a considerable improvement as well.
> Far from it.
I prefer to conform to the standard traits as much as possible. The
moving from Boost to the standard is easier. The porting of C++11
libraries to Boost for non-conforming C++11 compilers also.
>> Indeed I suspect there's a huge amount of obfuscated code inherited
>> from mpl's broken-compiler-workarounds that can now be removed: not
>> only do we not support those compilers any more, but given that they
>> haven't been tested in heaven knows how long they're unlikely to
>> compile *any* of modern Boost anyway.
> That's certainly true. If we remove the obsolete workarounds from MPL
> and TypeTraits things will start looking much better.
>> In fact in C++11 it makes sense to me have:
>> namespace boost{ namespace mpl{
>> template <bool b>
>> using bool_ = std::integral_constant<bool, b>;
> Interesting. This makes the std type traits conform to my second
> definition above, so that "using std::is_member_pointer;" (say) is a
> legitimate implementation of boost::is_member_pointer even when
> derivation from mpl::bool_ is required.
> I'm not sure that this is a conforming mpl::bool_ though. It almost
> is. But mpl integral constants need to have a nested ::tag
> (integral_c_tag), and std::integral_constant doesn't have one. Maybe
> this requirement can be dropped. Maybe it can't. I don't know.
We agree here. The preceding bool_ definition is no equivalent to the
MPL current definition.

The question is whether we need tag dispatching for the result of a
trait. IMHO not.

mpl::bool_could be defined

template <bool b>
struct bool_ : std::integral_constant<bool, b> {
   using tag integral_c_tag;
   using type bool_<b>;

IMO, the next and prev meta-functions can be implemented outside the
class but this is another history.


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