Iterator returning a reference to object of an abstract class?

I have an Element class which is abstract and I would like to have an
object of the Iterator class to iterate over a range of elements.

I would like to use std::for_each to instrument the iteration, which
forces me to have certain interface on the Iterator class.

struct Element {
virtual ~Element() = 0;
};

struct Iterator {
bool operator!=(Iterator const& ) const;
Iterator& operator++();

// The returned value of this function is the motivation of my
post
// Please, see the comments below the code.
Element& operator*() const;
};

struct Range {
Iterator begin() const;
Iterator end() const;
};


and the client code:

void action(Element const& );
void main()
{
Range range;
std::for_each(range.begin(), range.end(), action);
}


Now, after reading some earlier posts, I get the impression that
experience dictates that iterators should return objects by value. In
my case, however, the Element class is abstract, and therefore I
cannot return an object of that class by value.

I must also point out that in this case, so far clients are not
interested in holding references to values returned by the iterator
beyond the next call to operator*. They simply want to use the objects
and forget about them prior to getting the next object from the
iterator.

Thus, I see no need to return pointers (smart pointers, or what have
you) to objects allocated in the heap. Having said that however, I
should expect that, in the future, new clients may require to hold
references to objects beyond the next call to the operator* on the
iterator. In anticipation of that need, I would like to come up with a
design that, while it does not add lots of unnecessary complexity,
will effortlessly accommodate that future need.

Any comments?

re: Iterator returning a reference to object of an abstract class?

Belebele wrote:int main()
Oh, what nonsense! Now you're falling into another extreme. First,
your iterator owned the object and returned a reference to it upon
request, but then the reference would become invalid as soon as the
iterator moves onto the next object (which prompted me to suggest
retuning an object instead). Now, the object is actually owned by
the "Range", and there is no concern about the validity of the
reference returned by the iterator. So, return a reference. It's
going to be valid as long as the Range where the object lives keeps
it valid. IOW, disconnect the object and the iterator. Only have
the connection between the iterator and the container it traverses.
If your "Iterator" is specific to your "Range", you should make
the Iterator class a nested class in Range, most likely. Thus
a semantic relation will be established and the design intent will
be very clear.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

re: Iterator returning a reference to object of an abstract class?

Belebele a écrit :How do you handle affectation with operator=() or copy construtor?
Each subclass should define a Derived::operator=(const Element& );
Which limit the usage of Element or do you have a specific interface you
did not mentionned here (like some protected deep copy operator) ?

This kind of case never happen in the STL because you cannot define a
container of pure abstract class (unless by pointer).
If you want to create a STL iterator, you must define traits for your
iterator (google for it and you will find models).
If you are only interested in the for_each algorithm with begin() and
end() as parameter, you would better create a member function
template<typename Functor>Range::for_each(Functor& f) that iterate the
functor on all elements. That would save you the cost of defining an
iterator and make Array a container.
Michael

re: Iterator returning a reference to object of an abstract class?

On Feb 7, 5:24 pm, Michael DOUBEZ <michael.dou...@free.frwrote:So far, I have not had a need for neither shallow- nor deep-copy
semantics, so yes, I hide both the copy constructor and the operator=.
Even though I have only seen the need to traverse the entire sequence,
I am pretty sure I will be using other algorithms pretty soon.