Boost logo

Boost :

Subject: Re: [boost] [mpl] ForwardIterator concept recursion
From: Marcin Zalewski (marcin.zalewski_at_[hidden])
Date: 2009-09-09 09:43:44

I have noticed now that the MPL documentation actually says:

"An iterator i is incrementable if there is a "next" iterator, that
is, if next<i>::type expression is well-defined; past-the-end
iterators are not incrementable."

I guess this takes care of the recursion by cutting it off when it is
no longer possible. It seems that such requirement can be implemented
with Doug's technique that I linked to in my previous email.


On Tue, Sep 8, 2009 at 11:53 PM, Marcin
Zalewski<marcin.zalewski_at_[hidden]> wrote:
> I have been trying to implement a concept for mpl ForwardSequence, and
> besides the lack of const expr requirements in the latest version of
> concepts I have stumbled across the problem of concept recursion. One
> example of such recursion is the ForwardIterator [1] concept. The
> requirement on the next<i>::type type is that it must be a
> ForwardIterator. One could try to write a concept like that:
> concept ForwardIteratorStatic<typename I> {
>  typename deref;
>  typename next;
>  requires ForwardIteratorStatic<next>;
> }
> But for the above concept, the ConceptGCC compiler gives an error.
> Also, this should not compile according to the latest concepts
> proposal that states that a concept is not defined until the closing
> brace of the concept body. As for now, I think that one can try to
> apply technique described by Doug [2]:
> concept IteratorStatic<typename I> { }
> concept ForwardIteratorStatic<typename I> : IteratorStatic<I> {
>  typename deref;
>  typename next;
>  requires IteratorStatic<next>;
> }
> But to get to my question finally, I wonder if the recursion in mpl is
> intentional and thought out, or is it an accident that should be
> re-examined. If the decision was indeed thought out, I really wonder
> what would be a reasonable semantics of concept recursion.
> Cheers,
> Marcin
> [1]
> [2]

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