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