Quote:Original post by EasilyConfused
Hey programmer16.

I hope this isn't taken as criticism but I was just wondering what would happen if you were halfway through a MoveNext() sequence and called a function that, within that, had to run through the WordDictionary seperately?

I had a problem with a list of game objects once that provided an interface like yours with a position marker internal to the list class. During one of the iterations, it called another function that also had to iterate through the list and it all went a bit mad.

typedef dfg::Vector<YourTypeHere> Vector;

Vector::Enumerator Enumerator = Vector.GetEnumerator();
while(Enumerator.MoveNext())
{
    // do stuff using Enumerator.GetCurrent();
    Vector::Enumerator EnumeratorB = Vector.GetEnumerator();
    while(EnumeratorB.MoveNext())
    {
        // do stuff using EnumeratorB.GetCurrent();
    }
}

Item *operator()(Item *I=0){ return(I ? I->Next : Top); }

for(Item *I=Items();I;I=Items(I)) I->DoStuff();

Quote:Original post by EasilyConfused
Yeah, thought you'd probably already thought of that.

When I had the problem with my game list, I ended up with a very simple solution, since the list was specific to game items and they had a next pointer. I just added this inline member function to the list:

Item *operator()(Item *I=0){ return(I ? I->Next : Top); }

Then I could just do:

for(Item *I=Items();I;I=Items(I)) I->DoStuff();

That was nice and concise but I'm now realising that it was a bad design to have a specific list like that and also probably violates the principle of least surprise.

I should have generalised the list so it wasn't specific to the game items. The iterator approach you describe above seems like a much cleaner solution.

I must admit though that with your new design, I'd be hard pressed to resist implementing MoveNext as operator++, then operator* and operator-> for access, then you're pretty much back to the STL iterator design.

[EDIT] I just read your forum post on this subject and realised I'm not adding anything new to the debate here [smile].

Quote:Original post by Deyja
I'm not seeing any advantage in this design over iterators and standard algorithms.

In fact, without an iterator interface, I can't use your containers with standard algorithms anyway.

Quote:Original post by EDI
This is a Bad Idea (TM),

I used a similar system in my home-rolled containers, so as you stated first off your iterator object must be an external object so that you dont get nested enumeration issues. Second, you should just get used to:

std::vector<int>::iterator it=vec.begin();
while(it!=vec.end())
{
int i=*it;

++it;
}

I am currently removing my:

EnumRewind, EnumWhile, EnumNext functions as well as my home-rolled container classes from Morning's Wrath, that should be a signal that this may not be the way to go about things :)

Quote:Original post by Saruman
I don't mean to be rude but I have to say that you are definately going down the wrong road with this and should be using the standard way of doing things.

template<class T> void write(ofstream &os,T i)
{
    while(!i.at_end()) os << *i++;
}

void f()
{
    ofstream os("test.txt");

    std::vector v; // fill with values
    write(os,v.end_aware_iterator());

    std::list l; // fill with values;
    write(os,l.end_aware_iterator());
}