Итераторы C++ и наследование

Если вам сойдет с рук сделать List<T>::iterator невиртуальным, то делегирование виртуальности от добавления в список упрощает задачу:

template<typename T>
class List
{
    virtual void add_assign(iterator& left, int right) = 0;

public:
    class iterator
    {
        const List* list;
        const T* item;
    public:
        iterator(const List* list, const T* item) : list(list), item(item) {}

        iterator& operator +=(int right)
        {
            list->add_assign(*this, right);
            return *this;
        }
        static iterator operator +(iterator const& left, int right)
        {
            iterator result = left;
            result += right;
            return result;
        }
    };

    virtual iterator begin() const = 0;
    virtual iterator end() const = 0;
};

В противном случае (например, если итераторам нужно хранить значительно отличающиеся данные), вам придется делать обычную скучную реализацию указателя на реализацию, чтобы получить свою виртуальность:

template<typename T>
class List
{
    class ItImpl
    {
        virtual ItImpl* clone() = 0;
        virtual void increment() = 0;
        virtual void add(int right) = 0;
    };
public:
    class iterator
    {
        ItImpl* impl;
    public:
        // Boring memory management stuff.
        iterator() : impl() {}
        iterator(ItImpl* impl) : impl(impl) {}
        iterator(iterator const& right) : impl(right.impl->clone()) {}
        ~iterator() { delete impl; }
        iterator& operator=(iterator const& right)
        {
            delete impl;
            impl = right.impl->clone();
            return *this;
        }

        // forward operators to virtual calls through impl.
        iterator& operator+=(int right)
        {
            impl->add(right);
            return *this;
        }
        iterator& operator++()
        {
            impl->increment();
            return *this;
        }
    };
};

template<typename T>
static List<T>::iterator operator+(List<T>::iterator const& left, int right)
{
    List<T>::iterator result = left;
    result += right;
    return result;
}

template<typename T>
class MagicList : public List<T>
{
    class MagicItImpl : public ItImpl
    {
        const MagicList* list;
        const magic* the_magic;
        // implement ...
    };
public:
    iterator begin() const { return iterator(new MagicItImpl(this, begin_magic)); }
    iterator end() const { return iterator(new MagicItImpl(this, end_magic)); }
};

Среди итераторов есть кое-что очень важное, называемое Iterator Category:

• Итератор ввода
• Выходной итератор
• Форвардитератор
• Двунаправленный итератор
• Итератор случайного доступа

Каждая категория определяет точный набор операций, которые эффективно поддерживаются итератором.

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

Я думаю, что ваш дизайн пахнет.

Итак, проблема в том, что реализация итератора для ListImpl1 будет отличаться от реализации для ListImpl2. Я обошел это, используя оболочку ListIterator, содержащую указатель на ListIteratorImpl с подклассами ListIteratorImpl2 и ListIteratorImpl2, но все это становится довольно запутанным, особенно когда вам нужно реализовать оператор + в ListIterator.

Этот дизайн прекрасен ИМХО, я не вижу в нем ничего грязного. За исключением равенства и вычитания, операции итератора могут быть довольно легко реализованы виртуальной функцией, поэтому у вас будет что-то вроде

class ListIteratorInterface // abstract
{
protected:
  virtual Data& operator*()=0;
  // and other operations
};
class ListIteratorA;
class ListIteratorB; // implementation of the above
class ListIterator
{
  ListIteratorInterface* impl_;
public:
  // when you create this, allocate impl_ on the heap
  // operations, forward anything to impl_
};

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

В качестве альтернативы вы можете рассмотреть статически полиморфные классы списков, а не полиморфизм времени выполнения.

Скажем, у меня есть шаблонный базовый класс «Список» и два подкласса «ListImpl1» и «ListImpl2».

Что именно вы получаете, используя здесь наследование?