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

From: Andy Little (andy_at_[hidden])
Date: 2006-08-04 22:31:34

"David Abrahams" <dave_at_[hidden]> wrote in message
news:upsfhdfsd.fsf_at_boost-consulting.com...
> "Andy Little" <andy_at_[hidden]> writes:
>
>> "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
>
> That's meaningless.  Just leave out the "where."

What's meaningless? the AnyType Concept or just the where?

>> 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
>
> Well, your example is too vague for me to understand.  Maybe if you
> could provide some notation...

I think even Anytype has some requirements. The only two I can think of are:

typeid(AnyType)
AnyType*

An aspiration
AnyType  f();

BOOST_TYPEOF(f());

>> The union of ConstAnyType  with  NonConstAnyType is  AnyType.
>
> You have a problem with ConstType and NonConstType?  "Any" adds nothing here.

Ok.

>> Obviously things can become much more complicated than this in
>> practise, so its a useful general Concept, but maybe not inside mpl.
>
> Nothing you've written here leads me to conclude that it's useful.
> Please show a real example (or just retract that claim; I doubt it's
> central).

What claim? That an AnyType Concept may not be useful in MPL?
If it was useful it would be there right? Hence I deduce that *maybe* it
wasnt found to be useful inside MPL.
In general though an AnyType Concept would be a useful statement that there are
no restrictions on the types allowed. It expresses the current situation
regarding template parameters as a Concept. Its the most fundamental Concept of
type and already exists in every template type parameter. In fact it is
currently the only Concept we have.

>>> 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
>
> No, that's called CopyConstructible.

At compile time?

>> 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
>
> That's certainly not in the minimal set of requirements, since a
> proven useful set (the one in MPL) doesn't include it.

Its roughly equivalent to the member ::tag requirement, currently at
least, required by mpl::equal_to when acting on models of mpl::IntegralConstant

>>>> 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" :).
>
> Aleksey's point here is that you are now advocating *more*
> specification, which contradicts your subject line.

Nope. Having next prior as requirements but not the usual operations on integers
strikes me as odd. IOW if remove the next prior requirements, that is less
specification, not more.

>>>> 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.
>
> Technically that's right, but I don't think it's a serious omission
> when taken against a background of short,int,long,... all of which
> have the same problem.

So what? The compiler cant warn about it at runtime. Maybe its not a problem for
the use mpl::IntegralConstant is designed for.

regards
Andy Little