Boost logo

Boost Users :

From: Louis Lavery (Louis_at_[hidden])
Date: 2006-04-02 11:31:56


Hello,

I've been reading "The Cursor/Property Map Abstraction"
Doc.No: N1873=05-0133 by Dietmar Kühl and David Abrahams.

I like the idea of cursors, they're so much simpler than C++
iterators, but I am concerned regarding dereferencing a cursor.
Here's the relevant paragraph...

"The presence of a dereference operator on cursors might seem strange,
since since the goal is to separate access from traversal. For instance,
the values of a property map could be read as pm(c) instead of pm(*c).
It turns out that the dereference operation is required in order to
reasonably support traversal adapters. If you have a property map that
accepts foo_cursor arguments, it may not be designed to accept a
reverse_cursor<foo_cursor> directly. Like so many others, this problem
is solved by adding a level of indirection: dereferencing a cursor
yields an intermediate key, and the key type of a traversal adapter is
the same as that of its underlying iterator."

...and my concern is that if all cursors yield the same key type then
this could lead to hard to find bugs.

EG. Suppose we have a property map (pm) of Ts and that it's useful
to reverse it but that reversing it requires reversing the Ts[1],
not just applying a reverse cursor.
I guess we'd wrap pm in a reversed property map (rpm) that supplies
its own cursors (rc), some thing like...

t = pm(*c); // forward access
t = rpm(*rc); // reversed access - returns reversed t

...but, of course, there's nothing to stop...

t = pm(*rc);
t = rpm(*c);

But may be there are other advantages that outweight this drawback?
I'd be interested to know. Also, has there been any further work
on the proposal?

Thanks, Louis.

[1] EG. Reversing a 2D curve made from arcs of circles could well
     require reversing the direction of the returned arcs.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net