"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsfhdfsd.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m1k65tgzvi.fsf@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)
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 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.
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.boost-consulting.com