
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20060801 10:42:13
"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
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 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" :).
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:
>>
>> http://tinyurl.com/len5m
>>
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk