Boost logo

Boost Users :

From: Duane Murphy (duanemurphy_at_[hidden])
Date: 2002-06-04 09:25:05


--- At Tue, 4 Jun 2002 09:45:12 -0400, David Abrahams wrote:
>"Duane Murphy" <duanemurphy_at_[hidden]> wrote in message
>news:20020604050249.610_at_mail.murphyslogic.com...
>> --- At Tue, 4 Jun 2002 00:05:46 -0400, David Abrahams wrote:
>> I dont have any iterator to assign policies to yet.
>
>The policies are supposed to implement the core operations of the iterator
>using the Base object. You can, of course, stick the neccessary
>functionality in the Base object and use the default policies, as you are
>doing, but it seems a little unnatural to me.
>
>> This is usually a forward iterator if copying
>> is practical given the nature of the API. Basically in the example, the
>> iterator would hold a DIR structure and use the standard DIR APIs to
>> "increment" and dereference the structure as required.
>>
>> So, what is the "normal" way of creating an iterator out of thin air as
>> it were?
>
>If you have a DIR structure, I would use that as the Base object directly,
>then write a Policies class which implements the operations on it.

[ Giant light bulb goes on! ]

Now I get it. Thank you very much for this explaination.

Everytime I write an iterator there is almost always some data structure
that is required in the iterator for me to use. You have simply
"constructed" that part of the iterator through the base template
parameter. I have been working way to hard to make this work.

When I first did things this way, I went and wrapped some data structure
in all kinds of methods. I see now that I was making too much work for
myself. Simply specify the object that is the base and access it
directly; no additional objects needed. Treating base as a member
variable is acceptable.

Thank you for this enlightening discussion. I will follow this pattern
for my future iterators.

 ...Duane


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net