From: David Abrahams (dave_at_[hidden])
Date: 2006-08-03 11:01:38
"Andy Little" <andy_at_[hidden]> writes:
> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
>> 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."
> 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
>> 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
> 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 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.
>>> 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.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk