[iterators] New iterator concepts in TR1?
The Boost.Iterator library includes the "New Iterator Concepts" proposal which mentions this: "This is a revised version of n1550=03-0133, which was accepted for Technical Report 1 by the C++ standard committee's library working group." But in reading the TR1 doc I can get (the N1836 draft) I can't see a mention of this. Is the above statement incorrect? If correct, is there a TR1 doc that includes the new iterators? I'm asking so I can refer to it for the tree docs. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Oct 2, 2006, at 10:14 PM, Rene Rivera wrote:
The Boost.Iterator library includes the "New Iterator Concepts" proposal which mentions this:
"This is a revised version of n1550=03-0133, which was accepted for Technical Report 1 by the C++ standard committee's library working group."
But in reading the TR1 doc I can get (the N1836 draft) I can't see a mention of this. Is the above statement incorrect? If correct, is there a TR1 doc that includes the new iterators? I'm asking so I can refer to it for the tree docs.
The above statement *was* correct. The new iterator concepts were initially voted into TR1, but were later removed. Perhaps someone who was in the room when it happened could tell you more, but I'm hoping the new iterator concepts come back for C++0x. Concepts (the language feature) and move semantics force us to fix the current iterator concepts. Doug
Douglas Gregor wrote:
The above statement *was* correct. The new iterator concepts were initially voted into TR1, but were later removed. Perhaps someone who was in the room when it happened could tell you more, but I'm hoping the new iterator concepts come back for C++0x. Concepts (the language feature) and move semantics force us to fix the current iterator concepts.
Thanks Doug. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Tue, 2006-10-03 at 08:58 -0400, Douglas Gregor wrote:
The above statement *was* correct. The new iterator concepts were initially voted into TR1, but were later removed. Perhaps someone who was in the room when it happened could tell you more, but I'm hoping the new iterator concepts come back for C++0x. Concepts (the language feature) and move semantics force us to fix the current iterator concepts.
Jumping in the discussion with a diverging topic, sorry... Speaking of iterators, is there any attempt at making OpenMP extensions to deal with iterators (or OpenMP friendly iterators). Multicore processors are becoming the rule rather than the exception and OpenMP seems (I'm still making my first experiments) very constrained in the loops it can deal with (basically loop controled by signed integers). Of course, there are ways of using OpenMP with C++ and iterators, but this destroys quite a bit the programming model using loops over iterators. I just wonder whether this has raised some concern in the C++ community. Theo.
On Oct 3, 2006, at 11:43 AM, Theodore Papadopoulo wrote:
On Tue, 2006-10-03 at 08:58 -0400, Douglas Gregor wrote:
The above statement *was* correct. The new iterator concepts were initially voted into TR1, but were later removed. Perhaps someone who was in the room when it happened could tell you more, but I'm hoping the new iterator concepts come back for C++0x. Concepts (the language feature) and move semantics force us to fix the current iterator concepts.
Jumping in the discussion with a diverging topic, sorry... Speaking of iterators, is there any attempt at making OpenMP extensions to deal with iterators (or OpenMP friendly iterators).
We in the Open Systems Laboratory at Indiana University have an active research project that concerns making OpenMP more friendly for modern C++. Among other things, it will enable iterator loops to be parallelized with OpenMP directives. I don't know when the result will be stable enough for public consumption, but I expect we'll have a limited prototype available in the next six months.
Multicore processors are becoming the rule rather than the exception and OpenMP seems (I'm still making my first experiments) very constrained in the loops it can deal with (basically loop controled by signed integers). Of course, there are ways of using OpenMP with C++ and iterators, but this destroys quite a bit the programming model using loops over iterators.
Right. You have to jump through a lot of hoops to make OpenMP work with C++. We've managed to find workarounds and tricks that get some things working, but we really need extensions to OpenMP to make it usable in this context. Anyway, we're in danger of drifting off-topic for the Boost developer's list... Cheers, Doug
Rene Rivera <grafikrobot@gmail.com> writes:
The Boost.Iterator library includes the "New Iterator Concepts" proposal which mentions this:
"This is a revised version of n1550=03-0133, which was accepted for Technical Report 1 by the C++ standard committee's library working group."
But in reading the TR1 doc I can get (the N1836 draft) I can't see a mention of this. Is the above statement incorrect? If correct, is there a TR1 doc that includes the new iterators? I'm asking so I can refer to it for the tree docs.
It was accepted and then later ejected. We need to get rid of that text. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Douglas Gregor -
Rene Rivera -
Theodore Papadopoulo