Iterators and containers STL

[Merlin]

Hi,

I am a C++ developer and would like to implement container classes for
various types of objects. I use MS Visual C++ to compile my code.
Nevertheless I like to write code that is independent from MFC and
intentionally I am trying to avoid inheriting from CList and CArray
classes. Recently, I became familiar with iterators and have read many
articles including the GOF description on what they help to achieve.
My understanding so far has led me to believe to the following

A) Client has to declare the container, populate it and THEN
instatiate the iterator by passing the container as an argument. This
approach does not require deleting the iterator object as it is
declared on the stack (local). However, the client must know the type
of the container class (whether it is a List, etc)

B)polymorphic iterators use the factory method to create the iterator
when the client requests it. This apporach will require the client to
delete the iterator at some stage.

The second approach suggests that the container provides only 1 method
to create an iterator... What happens if we like to have a forward
iterator and a backward iterator for a container that uses the B
approach above... does this mean we will have 2 methods in its
interface, eg CreateForwardIterator() and CreateBackwardIterator()?

The problem with deletion can be resolved with a proxy pattern but can
this be inefficient in any way?

The GOF book suggests an interface for the iterator which is textual.
Should I use that interface or adopt the style where one uses pointer
operators?

Now lets say the above questions are answered and I have decided on
which iterator (A or B) to use and established its interface. What
will my container class inherit from? Will it inherit from an
appropriate STL container class? If so doesnt this mean that I dont
need to implement any iterator classes as STL already supports
iterators for its containers. If I did inherit from a container class
in STL would anyone see the benefits of wrapping up the STL iterators
in my own classes.

Obviously I could just write my container classes from scratch but
that wouldnt be taking advantage of code reuse. Can I implement the
iterator pattern and use STL at the same time...

I hope I have made sense....

Many Thanks

Merlin

[Claudio Puviani]

"Merlin" <me********@hotmail.com> wrote

Hi,

I am a C++ developer and would like to implement container classes for
various types of objects. I use MS Visual C++ to compile my code.
Nevertheless I like to write code that is independent from MFC and
intentionally I am trying to avoid inheriting from CList and CArray
classes. Recently, I became familiar with iterators and have read many
articles including the GOF description on what they help to achieve.
My understanding so far has led me to believe to the following

A) Client has to declare the container, populate it and THEN
instatiate the iterator by passing the container as an argument. This
approach does not require deleting the iterator object as it is
declared on the stack (local). However, the client must know the type
of the container class (whether it is a List, etc)

B)polymorphic iterators use the factory method to create the iterator
when the client requests it. This apporach will require the client to
delete the iterator at some stage.

The second approach suggests that the container provides only 1 method
to create an iterator... What happens if we like to have a forward
iterator and a backward iterator for a container that uses the B
approach above... does this mean we will have 2 methods in its
interface, eg CreateForwardIterator() and CreateBackwardIterator()?

The problem with deletion can be resolved with a proxy pattern but can
this be inefficient in any way?

The GOF book suggests an interface for the iterator which is textual.
Should I use that interface or adopt the style where one uses pointer
operators?

Now lets say the above questions are answered and I have decided on
which iterator (A or B) to use and established its interface. What
will my container class inherit from? Will it inherit from an
appropriate STL container class? If so doesnt this mean that I dont
need to implement any iterator classes as STL already supports
iterators for its containers. If I did inherit from a container class
in STL would anyone see the benefits of wrapping up the STL iterators
in my own classes.

Obviously I could just write my container classes from scratch but
that wouldnt be taking advantage of code reuse. Can I implement the
iterator pattern and use STL at the same time...

Why don't you just look at how the standard containers implement their iterator
mechanism and emulate that. Better yet, why not just use standard containers?

Claudio Puviani

[Chris Theis]

"Merlin" <me********@hotmail.com> wrote in message
news:12**************************@posting.google.c om...

Hi,

I am a C++ developer and would like to implement container classes for
various types of objects. I use MS Visual C++ to compile my code.
Nevertheless I like to write code that is independent from MFC and
intentionally I am trying to avoid inheriting from CList and CArray
classes. Recently, I became familiar with iterators and have read many
articles including the GOF description on what they help to achieve.
My understanding so far has led me to believe to the following

A) Client has to declare the container, populate it and THEN
instatiate the iterator by passing the container as an argument. This
approach does not require deleting the iterator object as it is
declared on the stack (local). However, the client must know the type
of the container class (whether it is a List, etc)
There are implementations of the iterator pattern which follow this way. But
(IMHO) the better approach is the one favored by the standard library
(former STL) with the container supplying an appropriate iterator. This is
much more elegant and less cumbersome because otherwise one would have to
handle cases where for example a user tries to pass a container to a random
iterator but the container does not supply random element access.

B)polymorphic iterators use the factory method to create the iterator
when the client requests it. This apporach will require the client to
delete the iterator at some stage.

[SNIP]
Obviously I could just write my container classes from scratch but
that wouldnt be taking advantage of code reuse. Can I implement the
iterator pattern and use STL at the same time...

Of course you can implement the iterator pattern and use the STL but the
question is rather why would you go all the way and redo work somebody has
already done (& optimized!!) for you. Why not go ahead and use the standard
containers and their iterators?

Regards
Chris

[Merlin]

"Claudio Puviani" <pu*****@hotmail.com> wrote in message news:<Ii*********************@news4.srv.hcvlny.cv. net>...

"Merlin" <me********@hotmail.com> wrote

Hi,

I am a C++ developer and would like to implement container classes for
various types of objects. I use MS Visual C++ to compile my code.
Nevertheless I like to write code that is independent from MFC and
intentionally I am trying to avoid inheriting from CList and CArray
classes. Recently, I became familiar with iterators and have read many
articles including the GOF description on what they help to achieve.
My understanding so far has led me to believe to the following

A) Client has to declare the container, populate it and THEN
instatiate the iterator by passing the container as an argument. This
approach does not require deleting the iterator object as it is
declared on the stack (local). However, the client must know the type
of the container class (whether it is a List, etc)

B)polymorphic iterators use the factory method to create the iterator
when the client requests it. This apporach will require the client to
delete the iterator at some stage.

The second approach suggests that the container provides only 1 method
to create an iterator... What happens if we like to have a forward
iterator and a backward iterator for a container that uses the B
approach above... does this mean we will have 2 methods in its
interface, eg CreateForwardIterator() and CreateBackwardIterator()?

The problem with deletion can be resolved with a proxy pattern but can
this be inefficient in any way?

The GOF book suggests an interface for the iterator which is textual.
Should I use that interface or adopt the style where one uses pointer
operators?

Now lets say the above questions are answered and I have decided on
which iterator (A or B) to use and established its interface. What
will my container class inherit from? Will it inherit from an
appropriate STL container class? If so doesnt this mean that I dont
need to implement any iterator classes as STL already supports
iterators for its containers. If I did inherit from a container class
in STL would anyone see the benefits of wrapping up the STL iterators
in my own classes.

Obviously I could just write my container classes from scratch but
that wouldnt be taking advantage of code reuse. Can I implement the
iterator pattern and use STL at the same time...

Why don't you just look at how the standard containers implement their iterator
mechanism and emulate that. Better yet, why not just use standard containers?

Claudio Puviani

Hi Claudio

I have looked at them and I like what I see. I just want to get the
container behaviour in classes of my own through inheritance. To these
classes I will add additional behaviours. I just wanted to what place
GOF iterator pattern had in what I was trying to do...

Merlin

[Merlin]

"Chris Theis" <Ch*************@nospam.cern.ch> wrote in message news:<c6**********@sunnews.cern.ch>...

"Merlin" <me********@hotmail.com> wrote in message
news:12**************************@posting.google.c om...

Hi,

I am a C++ developer and would like to implement container classes for
various types of objects. I use MS Visual C++ to compile my code.
Nevertheless I like to write code that is independent from MFC and
intentionally I am trying to avoid inheriting from CList and CArray
classes. Recently, I became familiar with iterators and have read many
articles including the GOF description on what they help to achieve.
My understanding so far has led me to believe to the following

A) Client has to declare the container, populate it and THEN
instatiate the iterator by passing the container as an argument. This
approach does not require deleting the iterator object as it is
declared on the stack (local). However, the client must know the type
of the container class (whether it is a List, etc)

There are implementations of the iterator pattern which follow this way. But
(IMHO) the better approach is the one favored by the standard library
(former STL) with the container supplying an appropriate iterator. This is
much more elegant and less cumbersome because otherwise one would have to
handle cases where for example a user tries to pass a container to a random
iterator but the container does not supply random element access.

B)polymorphic iterators use the factory method to create the iterator
when the client requests it. This apporach will require the client to
delete the iterator at some stage.

[SNIP]

Obviously I could just write my container classes from scratch but
that wouldnt be taking advantage of code reuse. Can I implement the
iterator pattern and use STL at the same time...

Of course you can implement the iterator pattern and use the STL but the
question is rather why would you go all the way and redo work somebody has
already done (& optimized!!) for you. Why not go ahead and use the standard
containers and their iterators?

Regards
Chris

Hi Chris

Say you wanted to create a class for Points(geometric). In there you
would have a Function called

double GetDistance() const;

by inheriting Points from say std::vector you could add this member
function to this class and other methods deemed appropriate. At the
same time Points will be a vector and support all the algorithms that
a vector supports.

Merlin