[litwindow-users] Re: Conditional lists/filters

[Hajo K. <mai...@ha...>]

Hi,

 > As I was working on this, I noticed that there doesn't seem to be any 
check
 > that the iterator does not increment past the last element.  In 
particular
 > advance() seems susceptible to overrunning the container in the basic 
case.


that is correct. The current implementation follows the STL iterators 
closely and like them does not have any checks. Actually I am not sure 
if advance is really used at all or if it was just a failed attempt at 
starting with the bookmarks implementation.

 > In implementing the filter feature, I need to compare against the end
 > element in a few other locations too, but I don't see any way to access
 > end() or npos or whatever from within a container_iterator_imp_base 
subclass
 > or via access to the stl container's iterator.  Am I missing something?


No. If you need this you have to do it yourself.

 > While I was searching around looking for something within the 
iterator class
 > that would tell me if I was at the end, I stumbled across the boost
 > library's filtered iterator implementation.
 > (http://www.boost.org/libs/iterator/doc/filter_iterator.html) They 
appear to
 > address the boundary condition test by explicitly passing an end 
iterator.
 > I wonder if using it would be as simple as declaring the filtered 
iterator
 > as a litwindow container.


If it follows the STL container conventions, yes. If it doesn't, you 
will have to override the make_container_iterator and container_iterator 
mechanism.

BTW, I can *highly* recommend the boost library. I have all but 
finalized my decision to use boost with the Lit Window Library anyway.

 > filter to a rule in litwindow.  Once I resign myself to creating a new
 > container/iterator implementation for each filtered view, I find that the
 > independence of the iterator from the container prevents me from 
passing the
 > end value to the iterator.


A way around this are the container_converter::get_begin() / 
container_converter::get_const_begin methods. You have to override them 
anyway and can pass a pointer to the container to your iterator. STL 
iterators are fast but extremely simple. The IBM Open Class Library for 
example had a much more sophisticated concept. And iterators there 
always had a pointer back to the owning container.

BTW, passing end() to the iterator will not be sufficient in your case, 
since end() may change over time. So you really need the pointer to the 
container itself and get 'end()' everytime you need it.

 > I appreciate the direction thus far. The instructions were very 
clear. If I
 > can solve the 'end' problem, I think I can give this a try.  Otherwise, I
 > could embark on an exploration of boost library (which looks fairly
 > elegant), but I'm sure that will be time consuming too...


If you have the time, explore it. It is well worth it. Start with 
shared_ptr<>, if you are not already using it.

Best regards

Hajo