From: David Abrahams (dave_at_[hidden])
Date: 2006-07-28 10:16:13
"Andy Little" <andy_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote in message
>> "Andy Little" <andy_at_[hidden]> writes:
>>> A bool_ is stated to be a model of Integral Constant, but it patently doesnt
>>> can never meet the next / prior requirements.
>> Well, that's not strictly true. false_ and true_ can meet the
>> next/prior requirements just as well as int_<INT_MIN> and
>> int_<INT_MAX> can.
> Which is that they cant, so the statement is strictly true, INT_MIN and INT_MAX
> arent models of Integral Constant either, similar for unsigned types.
Yes, but then if int_<INT_MIN> is not a model, then by induction,
nothing is... beceause prev<int_<INT_MIN+1> >::type can't yield an
integral constant, and so on.
You can't claim that's because next/prev requiremens don't belong in
Integral Constant; we'd have the same problem with an "iterable"
concept. We just need a better way to specify what happens at the
endpoints of the range.
And, I should add, calling Integral Constant a "traits blob" is a
serious stretch. Integral Constant is a type concept that includes
"self-returning metafunction" mostly for convenience reasons. That
is, the primary role of Integral Constant is not as a metafunction.
>> Any bounded type has the same problem; maybe we need to be more
>> precise about what happens at the endpoints of the range.
> I have found it essential for maths on a compile time rational, but
> its more critical there.
> As regards bool_ , the debate is interesting for theoreticians but
> for practical programmers, it should be a separate Concept ..
You have said so many times but I have not seen any convincing
evidence that the existing concept definition is problematic other
than violating your personal sense of how things should be.
> simple and many of the type_traits functions should use that, which
> would remove the need for the true_or_false_type mullarkey.
I don't know what you're referring to.
> Also I suspect that the change from boost::is_same to std::is_same is going to
> break a lot of code, unless the mpl tag requiremnet is lifted ;-)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk