Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-05 12:42:35

"Andy Little" <andy_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
>> "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."
> 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)

Well, c'mon. That's like saying AnyName "can be written down."

    typedef X y;

is also required where X is any type. We don't need a new Concept for
that, because the C++ standard gives us "type."

> AnyType*

Not unless you want to rule out reference types.

> An aspiration
> AnyType f();

Not unless you want to rule out array and function types.

>>> 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?

No, that "AnyType would be a useful Concept."

> 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.

Yeah, it's called "type."

> In fact it is currently the only
> Concept we have.

?? We've defined several type concepts in MPL, such as "nullary

>>>> 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?

You'd better be more precise in your language. You can't literally
"return a value" 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

Not at all. It's one thing to require X::value or Y::tag, and quite
another to require is_constant<C>::value.

>>>>> 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.

Yes, but that's not necessarily a good criterion for determining what
should be a concept.

> IOW if remove the next prior requirements, that is less
> specification, not more.

If we just do that, sure, but you're advocating the replacement of
specification for the simple next/prior requirements with that of all
the math, comparison, and logic operations!

>>>>> 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.

I don't understand your point.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at