
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20060803 11:01:38
"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."
> 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...
> The union of ConstAnyType with NonConstAnyType is AnyType.
You have a problem with ConstType and NonConstType? "Any" adds nothing here.
> 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).
>> 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.
> 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.
>>> 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.
>>> 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.
 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