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

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-03 11:01:38

"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."

> 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...

> The union of ConstAnyType  with  NonConstAnyType is  AnyType.

You have a problem with ConstType and NonConstType?  "Any" adds nothing here.

> 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).

>> 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.

> 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.

>>> 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.

>>> 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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com