«Универсальный» итератор в c ++

Немного проще, чем вышеприведенное (в том, что он использует существующие библиотеки):

 #include <boost/static_assert.hpp> // or use C++0x static_assert
#include <boost/type_traits/is_same.hpp>

template <typename InputIterator>
void add_all_msgs( InputIterator it ) {
    BOOST_STATIC_ASSERT(( boost::is_same<
        typename std::iterator_traits<InputIterator>::value_type,
        Message>::value ));
    // ...
 

Если вы хотите, чтобы компилятор проверял, действительно ли итератор ссылается на объект Message, вы можете использовать следующий прием.

 template <typename InputIterator, typename ValueType>
struct AddAllMessages { };

template <typename InputIterator>
struct AddAllMessages<InputIterator, Message> {
  static void execute(const InputIterator &it) {
    // ...
  }
};

template <typename InputIterator>
void add_all_msgs(const InputIterator &it) {
  AddAllMessages<InputIterator, 
                 typename std::iterator_traits<InputIterator>::value_type>::execute(it);
}
 

Если вы не хотите использовать шаблон для функции add_all_msgs, вы можете использовать adobe :: any_iterator а>:

 typedef adobe::any_iterator<Message, std::input_iterator_tag> any_message_iterator;
void add_all_msgs(any_message_iterator begin, any_message_iterator end);
 

 #include <deque>
#include <vector>
#include <list>
#include <string>
using namespace std;

template<typename T>
void add_all_msgs(T &iter)
{

}

int _tmain(int argc, _TCHAR* argv[])
{
    std::deque<string>::iterator it1;
    std::vector<string>::iterator it2;
    std::list<string>::iterator it3;

    add_all_msgs(it1);
    add_all_msgs(it2);
    add_all_msgs(it3);


    return 0;
}
 

С итераторами в стиле C ++ сложно добиться динамического полиморфизма. operator++(int) возвращается по значению, с которым трудно справиться: у вас не может быть виртуальной функции-члена, которая возвращает *this по значению без ее нарезки.

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

Однако, если вам действительно нужен динамический полиморфизм, например, потому что вы не можете раскрыть реализацию add_all_msgs, как это сделал бы шаблон, тогда, я думаю, вы можете притвориться Java, например:

 struct MessageIterator {
    virtual Message &get() = 0;
    virtual void next() = 0;
    // add more functions if you need more than a Forward Iterator.
    virtual ~MessageIterator() { };  // Not currently needed, but best be safe
};

// implementation elsewhere. Uses get() and next() instead of * and ++
void add_all_msgs(MessageIterator &it);

template <typename T>
struct Adaptor : public MessageIterator {
    typename T::iterator wrapped;
    Adaptor(typename T::iterator w) : wrapped(w) { }
    virtual Message &get() {
        return *wrapped;
    }
    virtual void next() {
        ++wrapped;
    }
};

int main() {
    std::deque<Message> v;
    Adaptor<std::deque<Message> > a(v.begin());
    add_all_msgs(a);
}
 

Я проверил, что это компилируется, но не тестировал и никогда раньше не использовал этот дизайн. Я также не стал беспокоиться о константе - на практике вам, вероятно, понадобится const Message &get() const. И на данный момент адаптер не знает, когда остановиться, но и код, с которого вы начали, тоже не знает, поэтому я проигнорировал это. слишком. По сути, вам понадобится функция hasNext, которая сравнивает wrapped с конечным итератором, предоставленным конструктору.

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

[Edit: если подумать, вероятно, лучше иметь шаблон функции-заглушки add_all_msgs, который оборачивает свой параметр в адаптер, а затем вызывает real_add_all_msgs. Это полностью скрывает адаптер от клиента.]

 template <typename Iterator>
void add_all_messages(Iterator first, Iterator last)
 

использование:

 vector<message> v;
add_all_messages(v.begin(), v.end());
 

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