
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20060805 12:42:35
"Andy Little" <andy_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:upsfhdfsd.fsf_at_boostconsulting.com...
>> "Andy Little" <andy_at_[hidden]> writes:
>>
>>> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
>>> news:m1k65tgzvi.fsf_at_metacomm.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)
Well, c'mon. That's like saying AnyName "can be written down."
typedef X y;
is also required where X is any type. We don't need a new Concept for
that, because the C++ standard gives us "type."
> AnyType*
Not unless you want to rule out reference types.
> An aspiration
> AnyType f();
Not unless you want to rule out array and function types.
>>> 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?
No, that "AnyType would be a useful Concept."
> 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.
Yeah, it's called "type."
> In fact it is currently the only
> Concept we have.
?? We've defined several type concepts in MPL, such as "nullary
Metafunction."
>>>> 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?
You'd better be more precise in your language. You can't literally
"return a value" 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
Not at all. It's one thing to require X::value or Y::tag, and quite
another to require is_constant<C>::value.
>>>>> 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 heavyweight. 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.
Yep.
> Having next prior as requirements but not the usual operations on integers
> strikes me as odd.
Yes, but that's not necessarily a good criterion for determining what
should be a concept.
> IOW if remove the next prior requirements, that is less
> specification, not more.
If we just do that, sure, but you're advocating the replacement of
specification for the simple next/prior requirements with that of all
the math, comparison, and logic operations!
>>>>> 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.
I don't understand your point.
 Dave Abrahams Boost Consulting www.boostconsulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk