Блог

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

Обоснование этого заключается в том, что итератор будет отвечать за перечисление модулей в Windows, и я использую API CreateToolhelp32Snapshot / Module32First / Module32Next, чтобы избежать предварительной обработки всего списка модулей (например, приращение каждого итератора должно переходить к следующему модулю в списке по требованию, чтобы избежать ненужных накладных расходов.). Проблема с этим заключается в том, что эти API требуют использования «HANDLE» управляется API Toolhelp, поэтому у меня нет никакого контроля над «позицией» в списке, кроме вызовов First / Next.

Технически я мог бы разрешить копирование дескриптора, но тогда вы столкнетесь с проблемами, подобными этой:

 auto Iter1 = ModList.begin(); // Assume 'ModList' is an instance of my class which manages construction etc of my iterator
auto Iter2 = Iter1; // Both iterators now point to the first module in the list
  Iter1; // BOTH iterators now point to the second module in this list!! We just 'broke' the expected behavior of 'Iter2'.
  

Возможно ли определить STL-совместимый итератор (который будет работать со стандартными алгоритмами и т.д.), Который хорошо работает с типом значения, который нельзя скопировать или назначить?

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

Примечание: Я мог бы сделать тип значения подвижным, если это поможет.

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

Извините за плохо написанный вопрос, я не спал довольно долго, и мой мозг больше не хочет работать должным образом. : P Дайте мне знать, если требуется разъяснение.

Если вы пометите свой итератор как InputIterator, а не ForwardIterator, то описанное вами поведение не будет неожиданным. Увеличение InputIterator делает недействительными его копии, поэтому не имеет значения, на что они указывают после этого.

Вы можете использовать его со стандартными алгоритмами, которые принимают InputIterator, то есть именно те, которые могут быть разумно реализованы как однопроходные, а не многопроходные алгоритмы.

Однако, в зависимости от того, проверяют ли реализации вашего алгоритма теги итератора, вы можете не получить никакой помощи, гарантирующей, что вы не используете его неправильно. Нет разницы в «подписи» интерфейсов InputIterator и ForwardIterator, только в семантике, поэтому один только ввод во время компиляции не помогает.

Итератор должен логически ссылаться на элемент — он не должен быть элементом. Вам понадобится внутренняя коллекция модулей и итераторы, которые ссылаются на отдельные элементы в этой коллекции — точно так же, как итераторы stdlib. Увеличение итератора должно заставить его изменить, к какому фактическому элементу он относится, без изменения внутренней коллекции.

Для вашей конкретной проблемы вы могли бы создать коллекцию, которая продолжает итерацию toolhelp по требованию, всякий раз, когда кто-то ссылается на модуль, к которому вы еще не выполняли итерацию, вы добавляете дополнительные данные в коллекцию.