[mpl] ForwardIterator concept recursion
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] http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/forward-iterator... [2] http://www.osl.iu.edu/MailArchives/conceptgcc/2007/03/0084.php
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. Cheers, Marcin On Tue, Sep 8, 2009 at 11:53 PM, Marcin Zalewski<marcin.zalewski@gmail.com> 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] http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/forward-iterator... [2] http://www.osl.iu.edu/MailArchives/conceptgcc/2007/03/0084.php
I really wonder what would be a reasonable semantics of concept recursion.
The idea seems reasonable at first blush. We are used to such things from the start of maths and computer science. A problem seems to be that we are trying to be meta-meta when meta- alone suffices. I am reminded of when Buddha was asked about meta-existance (life after death). He said that we should be more concerned about the here and now, and less concerned about what may or may not come after. The same seems to be true in this and many other similar cases. Yes, compiler errors are terrible in C++ with deeply nested meta-code. We all know about it, and C++0x was going to 'fix' it with concepts. Alas, that was not to be. So we are stuck with template and typename and invalid use thereof rather than solving any real problems. Why not just move to D? I realise this is a C++ list, but even so this is also a list of intelligent people. Among many others, I have been bi-curious about D for some years but have yet to make the leap to make a project with it. But why not? I realise this is outlandish to post to boost. I am just openly wondering: why don't we all just move to D? AFIACT it links with all existing (non-templated) C++ libraries. Alex has put is own stake down some time ago. We all admire him. C++ has let us down, and even then we know that it will be years before boost can use even a modicum of C++0x let alone C++1x features. Or, we could get them and more now by just moving to D and be done with it. I don't have any action items to add here. I don't know what it would take to move to C++ to D. But I for one am open to the idea. Regards, Christian.
On 10 Sep 2009, at 10:26, Christian Schladetsch wrote:
I really wonder what would be a reasonable semantics of concept recursion.
The idea seems reasonable at first blush. We are used to such things from the start of maths and computer science.
A problem seems to be that we are trying to be meta-meta when meta- alone suffices. I am reminded of when Buddha was asked about meta- existance (life after death). He said that we should be more concerned about the here and now, and less concerned about what may or may not come after.
The same seems to be true in this and many other similar cases. Yes, compiler errors are terrible in C++ with deeply nested meta-code. We all know about it, and C++0x was going to 'fix' it with concepts.
Alas, that was not to be. So we are stuck with template and typename and invalid use thereof rather than solving any real problems.
Why not just move to D? I realise this is a C++ list, but even so this is also a list of intelligent people. Among many others, I have been bi- curious about D for some years but have yet to make the leap to make a project with it. But why not?
Why haven't I moved to D? Basically because it is under the control of one company, and one man. Has D got big enough yet that it could survive the end of Digital Mars? The GCC frontend hasn't been integrated into mainline GCC, the LLVM frontend is beta and similarly lives out of tree. A substantial, incompatible, rewrite of the language is currently in progress. I've used D for some fun side projects, it is a nicer language than C+ +. However, would I suggest using it at work, and risking a major, long-living software project on it? Unfortunatly not yet, and most people I've personally spoken to agree. Of course, this in no way means there shouldn't be a "boost for D", exploring the limits of what D can achieve, and pushing the corners of the language in multiple implementations, as boost already does for C++. Chris
participants (3)
-
Christian Schladetsch -
Christopher Jefferson -
Marcin Zalewski