Sign in to follow this  

Boost.Iterators + A Class Design Issue

This topic is 3573 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to write an abstract base class derived from boost::iterator_facade, from which all derived iterators in my application are to be descended. The reason being that I have to refer to iterators inside an interface and I need a general base type as a place holder to which I can refer and I don't want to use templates. Implementors of this interface will then create subtypes of this iterator based on the underlying data structure that they want to use. This gives them a lot of freedom. As discussed in the interoperability section of iterator_facade (here), the euqal() member function must be templatized in order to allow const and non-const versions of iterators be used interchangeably (of course where they're expected to behave so). The problem is that I have to make equal() a pure virtual member function on one hand in order to force derived types override it, but templated virtual functions on the other hand, are not valid. So I was wondering what the best approach is. How can I achieve both of these goals? What do you suggest? Thanks in advance [Edited by - Ashkan on March 7, 2008 4:11:29 AM]

Share this post


Link to post
Share on other sites
Boost iterator_facade isn't design to be a polymorphic base class - it has no virtual destructor.

It isn't designed to be a polymorphic base class because trying to use run-time polymorphism (i.e. inheritance) instead of compile time polymorphism (i.e. template) with iterators is almost always a mistake. Think really hard about whether you're doing the right thing.

Share this post


Link to post
Share on other sites
Good point. I hadn't noticed the non-virtual destructor of iterator_facade. What about a simple iterator class derived from iterator_facade that accepts some interface as part of its ctor and uses that interface to delegate the calls to the appropriate implementations. This way iterator traversal and element access are decoupled but the virtual function call is still there (it's only delegated to the interface). What do you think about this? Do you still consider this a bad design? Any ideas on acceptable approaches? Or should I just turn back to good old GetElement() virtual functions in my interfaces and forget about iterators? The virtual call is still there anyway.

/EDIT: Besides, this solves the templated virtual functions problem I stated in my first post.

Share this post


Link to post
Share on other sites

This topic is 3573 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this