Пользовательский итератор: как мне его отслеживать? - PullRequest
0 голосов
/ 21 июня 2010

У меня такая ситуация:

У меня есть класс, который отслеживает массив указателей.Я построил пользовательский итератор, который проходит через этот массив.

Моя проблема заключается в том, как сделать его потокобезопасным, особенно при увеличении / уменьшении?

Вот набросок соответствующих частейhave:

typedef fruit * iterator;

class fruits
{
  private:
    fruit ** flist;
    int n;     //keeps track of position in flist
    int count; //number of fruits

  public:
    iterator begin() {n=0; return fruit[n];}
    iterator end() {n=count; return fruit[n];}

    iterator operator++ ()
    {
      return fruit[++n];
    }
}

Проблема, которую я вижу, состоит в том, что если две части программы создают итератор, то вещи не будут работать.Как C ++ STL справляется с этим?

ОБНОВЛЕНИЕ: Я обнаружил ошибку своих способов.Итератор должен отслеживать, где он находится сам по себе.Для этого я создал класс итератора, встроенный в мой основной класс.Жизнь теперь хороша.

1 Ответ

5 голосов
/ 21 июня 2010

Стандартные контейнеры поддерживают свое состояние итерации в объектах итератора отдельно от контейнера, поэтому может быть несколько итераций для контейнера одновременно. Так что begin() и end() возвращают итераторы, но не меняют состояние контейнера; operator++ действует на итераторы, а не на контейнер. Для такого простого массива указатель (на fruit*, а не fruit) отлично работает как итератор, поэтому вы можете просто определить begin() и end():

iterator begin() {return flist;}
iterator end() {return flist + count;}

и используйте его так:

for (iterator i = my_fruit.begin(); i != my_fruit.end(); ++i)
    do_something_with(*i); // *i is a fruit*

Нет проблем с несколькими потоками, выполняющими это одновременно, если никто из них не пытается изменить контейнер.

С другой стороны, если это не учебное упражнение для лучшего понимания работы контейнеров и итераторов, вам гораздо лучше использовать std::vector, чем реализовывать свою собственную версию.

...