"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 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 The union of ConstAnyType with NonConstAnyType is AnyType. Obviously things can become much more complicated than this in practise, so its a useful general Concept, but maybe not inside mpl.
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 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 A simple model struct zero; template <> get_value<zero> {static int const value = 0;}; template <> struct is_constant<zero> : true_{}; With typeof, the type of the value of any StaticConstant can be found from that information template <typename C, typename Enable = void> struct get_value_type; template <typename T> struct get_value_type<T, typename boost::enable_if<is_constant<T> >::type> { typedef BOOST_TYPEOF_TPL(get_value<T>::value) type; }; <...>
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" :).
Sure. mpl::IntegralConstant is designed for use inside mpl. My problem arose because it was suggested to me that I make some of my own types models of mpl::Integral Constant. mpl::IntegralConstant obviously works very well inside of mpl. Its probably unfair to expect it to stand up for general purpose use, but that is the way it was suggested I use it. <...>
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. Means to detect these conditions (or not) might be dealt with by an Iterable Concept. <...>
I am currently trying to write Concepts for my own types parameters.. Bearing in mind that the inadequate Concept documentation was one of the main reasons that PQS was rejected., so now I am trying to get it right. One concept in the quan library is currently called StaticAbstractQuantity:
One goal of this Concept is that it should be possible to make a raw mpl::vector a model of StaticAbstractQuantity. In order to do this I have opted to use 'free' metafunctions for the associated types. For other developers working on the project I need to explain why this is a good idea. Of course developers can point to examples like this and say, mpl doesnt do that. Why should we?
I'm more than willing to work with you on fixing these cases.
As I said in another post, my major problem is not mpl's problem. It is the fact that many type_traits functions make use of mpl::integral_c. I'm wondering now wnat happens if I decide to change from using boost::is_same to std::is_same and so on. Ideally I would like to be able to use both mpl and std::is_same of course. That is possible, but currently I need to make my own specialisations of boost::mpl::equal_to and so on and specify that others do the same in order for things to work in all combinations. That is a bit messy. The other option is to create my own system that fits. <...>
N is a model of Iterable, Integral Constant and Runtime Evaluable.
I don't see how this is an improvement, given that IMO every integral constant is by definition Iterable and Runtime Evaluable.
I realise that things might be clarified if the mpl Integral Constant was always documented outside mpl (or at least in my own docs) as mpl::IntegralConstant . That I think agrees for instance with the way Conceptgcc documents things. I think the naming is the source of some confusion, maybe for me anyway. Integral Constant conveys to me something intended for general purpose use. If the mpl::integralConstant was always prefixed as such, one could then talk about an Integral Constant or maybe StaticIntegralConstant as being a general term as opposed to mpl::IntegralConstant which is designed for use inside mpl. Again though that isnt mpl's problem I guess. regards Andy Little