Re: [Boost-users] dereferencing cursors

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-03 08:20:10

Louis Lavery <Louis_at_[hidden]> writes:

> 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.

Nobody said that all cursors yield the same key type.

> 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.

That's a different transformation from reverse, which involves not
only a traversal (cursor) adapter, but also an access (property map) adapter.

> I guess we'd wrap pm in a reversed property map (rpm) 

Sure.

> that supplies its own cursors (rc),

?? Property maps don't supply cursors.

> 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);

There is something to stop it if you design it that way.

> But may be there are other advantages that outweight this drawback?

The ability to adapt traversal independently from access outweighs it.

> I'd be interested to know. Also, has there been any further work
> on the proposal?

Not much.

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com