Re: [boost] [mpl] Integral Constant is over specified

From: Andy Little (andy_at_[hidden])
Date: 2006-08-01 10:42:13

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:m1k65tgzvi.fsf_at_meta-comm.com...
> Andy Little writes:

<...>

> There is no absolute notion of the minimum set of requirements. For
> one, the abstract minimum is of course having no requirements at all,
> and obviously that would hardly give us a useful set of concepts.

AnyType would be a useful Concept, similar to the universal set:

Where A and B are models of AnyType

boost::is_same<A,B>

Another use of AnyType would be to check that you have covered all use cases,
when using enable_if for example.
I don't know what the notation would be but for example

The union of ConstAnyType  with  NonConstAnyType is  AnyType.
Obviously things can become much more complicated than this in practise, so its
a useful general Concept, but maybe not inside mpl.

>A
> meaningful minimum can only be derived from the relevant use cases,
> and it's pointless to discuss one without having those on the table.

The minimal use of a StaticConstant is to return its value

Where C is a model of StaticConstant
get_value<C>::value

A check on whether a type is a model of StaticConstant would also be useful:

where C is a model of StaticConstant.

is_constant<C>::value is true

A simple model

struct zero;

template <> get_value<zero> {static int const value = 0;};
template <> struct is_constant<zero> : true_{};

With typeof, the type of the value of any StaticConstant can be found from that
information

template <typename C, typename Enable = void>
struct get_value_type;

template <typename T>
struct get_value_type<T, typename boost::enable_if<is_constant<T> >::type>
{
    typedef BOOST_TYPEOF_TPL(get_value<T>::value) type;
};

<...>

>> In my use of integral constants, comparison for equality is the most
>> used operation, followed by arithmetic.  I have never used the next
>> ,prior functions. To me math ,comparison and logic operations are
>> more likely candidates for Integral Constant Requirements.
>
> IMO they are too heavy-weight. I understand your desire to have a
> concept encompassing these, but so far I don't see a compelling reason
> why Integral Constant should be such a concept (and I find it somewhat
> amusing that the title of this thread is "Integral Constant is over
> specified" :).

Sure. mpl::IntegralConstant is designed for use inside mpl. My problem arose
because it was suggested to me that I make some of my own types models of
mpl::Integral Constant. mpl::IntegralConstant obviously works very well inside
of mpl. Its probably unfair to expect it to stand up for general purpose use,
but that is the way it was suggested I use it.

<...>

>> It should also be stated that these constants arent perfect models
>> of integers, what happens in the case of math on constants of
>> different value_types , whether a given math operation is possible (
>> without overflow) and so on.
>
> Stated where?

In general, wherever it is possible that a mistake and particularly a silent one
can occur.  Means to detect these conditions (or not) might be  dealt with by an
Iterable Concept.

<...>

>> I am currently trying to write Concepts for my own types
>> parameters..  Bearing in mind that the inadequate Concept
>> documentation was one of the main reasons that PQS was rejected., so
>> now I am trying to get it right. One concept in the quan library is
>> currently called StaticAbstractQuantity:
>>
>> http://tinyurl.com/len5m
>>
>> One goal of this Concept is that it should be possible to make a raw
>> mpl::vector a model of StaticAbstractQuantity. In order to do this I
>> have opted to use 'free' metafunctions for the associated types. For
>> other developers working on the project I need to explain why this
>> is a good idea.  Of course developers can point to examples like
>> this and say, mpl doesnt do that. Why should we?
>
> I'm more than willing to work with you on fixing these cases.

As I said in another post, my major problem is not mpl's problem. It is the fact
that many type_traits functions make use of mpl::integral_c. I'm wondering now
wnat happens if I decide to change from using boost::is_same to std::is_same and
so on. Ideally I would like to be able to use both mpl and std::is_same of
course. That is possible, but currently I need to make my own specialisations of
boost::mpl::equal_to and so on and specify that others do the same in order for
things to work in all combinations. That is a bit messy. The other option is to
create my own system that fits.

<...>

>>>> N is a model of Iterable, Integral Constant and Runtime Evaluable.
>>>
>>> I don't see how this is an improvement, given that IMO every
>>> integral constant is by definition Iterable and Runtime Evaluable.

I realise that things might be clarified if the mpl Integral Constant was always 
documented outside mpl (or at least in my own docs) as
mpl::IntegralConstant . That I think agrees for instance with the way Conceptgcc
documents things. I think the naming is the source of some confusion, maybe for
me anyway. Integral Constant conveys to me something intended for general
purpose use. If the mpl::integralConstant was always prefixed as such, one could
then talk about an Integral Constant  or maybe StaticIntegralConstant as being a
general term as opposed to mpl::IntegralConstant which is designed for use
inside mpl. Again though that isnt mpl's problem I guess.

regards
Andy Little