[Xcb] xcb_foo_next/xcb_foo_end

[Jamey Sharp]

Hello!

On Thu, Jun 24, 2010 at 10:01 PM, Ulrich Eckhardt <doomster at knuut.de> wrote:
> Simple question: When I call xcb_foo_end(), do I really (as documented) get an
> "iterator pointing to the last element" of a sequence? Do I not rather get an
> iterator one element behind that? The point is that the returned iterator's
> "rem" field is zero, meaning "no element left". In terms of the STL[1], that
> would be a "past-the-end iterator".

You're right, and the documentation comments are wrong.

> That said, I wonder if anybody ever used this at all. In order to iterate over
> a sequence, just looking at the "rem" field of the iterator is so much easier
> than retrieving an iterator pointing past the end and then comparing (how?)
> the two.

It's actually used internally. When a reply contains one list after
another, the iterator for the second list is constructed by calling
the appropriate _end function on the first list. These past-the-end
iterators aren't intended to be used in the C++ STL style.

The reason these functions are exposed publicly is so that an
extension which has a list of items of a type from another extension
can successfully navigate that list. There may be a better way to do
that but it isn't obvious to me.

> Summary:
> 1. Should this be deprecated now and later be removed?

If there's a replacement for the internal use case, then I'd be happy
to deprecate the _end functions. I don't know that they'd ever be
removed though, since we're pretty strongly committed to API and ABI
stability in libxcb.

Jamey