[Boost-commit] svn:boost r49555 - sandbox/SOC/2006/tree/trunk

Subject: [Boost-commit] svn:boost r49555 - sandbox/SOC/2006/tree/trunk
From: ockham_at_[hidden]
Date: 2008-11-03 10:14:40

Author: bernhard.reiter
Date: 2008-11-03 10:14:39 EST (Mon, 03 Nov 2008)
New Revision: 49555
URL: http://svn.boost.org/trac/boost/changeset/49555

Log:
Update TODO.
Text files modified: 
   sandbox/SOC/2006/tree/trunk/TODO |    17 +++++++++++------                       
   1 files changed, 11 insertions(+), 6 deletions(-)

Modified: sandbox/SOC/2006/tree/trunk/TODO
==============================================================================
--- sandbox/SOC/2006/tree/trunk/TODO	(original)
+++ sandbox/SOC/2006/tree/trunk/TODO	2008-11-03 10:14:39 EST (Mon, 03 Nov 2008)
@@ -14,12 +14,10 @@
 [section TODO]
 
 General:
-* Future: Optimise insert_cursor for use with binary_tree insert and copy ctor 
-  (preorder copy; ideally, we can guarantee RAII for every single element)
-  and clear/dtor (postorder for_each).
-* Get insert_cursor to work with postorder copy, then with linear (ascending cursor)
-  versions. Check with other algorithms that use output cursors.
-* Caution: Iterative algorithms require ascending cursors!
+* Remove algorithm overloads for root_tracking_cursors, as track_root is a very
+  context dependent thing; so merge it into the general iterative algorithm versions.
+* Get insert_cursor to work with linear (ascending cursor) algorithm
+  versions.
 * Move some of the secondary stuff to a util/ dir? Is that what they're used for?
 * Redo testing. Right now, it's just chaotic.
 * Fix recursive algorithms for use with forest.
@@ -110,6 +108,13 @@
 * Start an RFC: what subtree algorithms should there be? In particular, of which of
   the STL's linear algorithms should there be a hierarchical version?
 
+Future: 
+* Do we need cursors that are not iterators, ie that provide to_begin() and to_end 
+  (and possibly to_parent()) operations, but not operator++() and --?
+* Optimise insert_cursor for use with binary_tree insert and copy ctor 
+  (preorder copy; ideally, we can guarantee RAII for every single element)
+  and clear/dtor (postorder for_each).
+
 Ask on the mailing list:
 
 * (iterator) Can we get rid of the need to declare iterator_core_access a friend (as we're already