Re: Virtual Iterators

From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 04/03/04 

Date: Sat, 03 Apr 2004 03:14:32 GMT

"richard.forrest1" <richard.forrest1@ntlworld.com> wrote...
> I have a problem with an abstract interface class whose implementation
> classes need to return different iterator types (but with the same
> value_types etc).
>
> Classes A and B both conform to the same abstract Interface class.
Interface
> has a pair of virtual functions begin() and end() that generate a typical
> STL style range. Classes A and B provide different implementations, maybe
> using different types of container. The problem is that, to conform to the
> interface, A and B must return the same type (or a derived type). They can
> not do this directly as their containers (and hence their iterators) are
of
> different types.
>
> class Interface
> {
> public:
> virtual VirtualIterator begin() = 0;
> virtual VirtualIterator end() = 0;
> };
>
> class A : public Interface
> {
> public:
> virtual VirtualIterator begin() {return
> make_virtual_iterator(container_.begin());}
> virtual VirtualIterator end() {return
> make_virtual_iterator(container_.end());}
> private:
> OneKindOfContainer container_;
> };
>
> class B : public Interface
> {
> public:
> virtual VirtualIterator begin() {return
> make_virtual_iterator(container_.begin());}
> virtual VirtualIterator end() {return
> make_virtual_iterator(container_.end())}
> private:
> AnotherKindOfContainer container_;
> };
>
> I think I see how to solve this problem by creating (as the example hints
> at) a kind of VirtualIterator class that maintains a pointer to heap based
> copy of the real iterator. But this issue must be fairly common and I
would
> much rather reuse a tried and tested solution than roll my own. I looked
at
> the boost iterator library but it does not seem to provide what I am
looking
> for. This made me a bit concerned because it seems to be very well thought
> out and comprehensive. Is there something fundamentally wrong with what I
am
> considering here? Or perhaps there is a really trivial solution I am
> overlooking?

For now, having only thought about your problem for a minute, I have only
one question: what are you going to do with 'VirtualIterator'? What does
its interface look like? I can see it that you are going to compare its
value to 'end' to know when to stop iterating, but I cannot imagine yet
if you have two different and unrelated containers, what else you could
do with a VirtualIterator object. Unless, of course, it's an iterator that
conforms to the iterator semantics laid out in the Standard, then it has to
have 'value_type' and 'reference' and ...

Do you have the answers?

V

Relevant Pages

  • Re: Virtual Iterators
    ... >> Classes A and B both conform to the same abstract Interface class. ... what are you going to do with 'VirtualIterator'? ... Unless, of course, it's an iterator ...
    (comp.lang.cpp)
  • Virtual Iterators
    ... Classes A and B both conform to the same abstract Interface class. ... using different types of container. ... virtual VirtualIterator begin= 0; ... copy of the real iterator. ...
    (comp.lang.cpp)
  • Re: comparison of objects
    ... the standard function is being used versus your redefinition. ... User's interface would give means to iteration, ... ** User and implementor interface: ... An iterable is an object for which an iterator can be defined. ...
    (comp.lang.lisp)
  • Re: Forevery() writable iterator mechanism in C# 3
    ... The '_itr_mth' LLP tag means 'Iterator Method'. ... Why would the interface need ref/out itself? ... A destructive operation will by definition be refelected in all references ... collection at all - that's really a major point of "yield", ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: javax.swing.text.HTMLDocument getIterator returns null for some Tags
    ... > I have encountered a problem which is reported multiple times in this ... > types, while working, equally mysteriously, for other tag types. ... It certainly is a peculiar interface, since a normal iterator ...
    (comp.lang.java.gui)