Возможно ли иметь трансформаторный Iterator в C++?

Question

Предположим, у меня есть итератор C++, который не только обходит структуру данных, но также применяет преобразование к элементам, когда он разыменован.

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

class ConstPixelIterator { 

    public: struct Pixel { 
    float Red; 
    float Green; 
    float Blue; 
    float Alpha; 
    }; 

    public: ConstPixelIterator(const Bitmap &bitmap); 

    // ...standard iterator functionality... 

    public: Pixel operator *() { 
    // Read from memory and convert pixel format-specific bytes into Pixel structure 
    } 

}; 

Теперь, если я хотел бы реализовать Некоммерческий -const iterator (т. е. разрешить пользователю изменять пиксели), каков наилучший способ сделать это?

Некоторые идеи я считал:

• я мог бы поставить аксессор методы в Pixel структуре вместо простых полей и дать ему ссылку на его владельца на домашний телефон. Это, однако, означает, что если пользователь изменил R, G, B и A, я бы четыре раза конвертировал пиксель в формат пикселя растрового изображения и записывал в память 4 раза.

• Я мог бы вернуть ссылку на пиксель из итератора и предоставить ему метод Update(), который необходимо вызвать, если пиксель был изменен. Это будет неинтуитивно понятным, и пользователи риска не смогут позвонить Update.

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

Answer 1

У нас есть существующий пример std::vector<bool>::iterator - который должен тянуть несколько трюков для записи в один бит.

Одним из решений является возвращение ProxyPixel. Он содержит ссылку на исходный пиксель. Вы заявили, что обновление R, G, B, A может вызвать 4 записи. Это правда и понятно. После первой записи только R, базовое изображение должно иметь обновленное значение R в конце концов.

Или вы счастливы принять окончательное обновление? В этом случае вы можете отложить обратную связь до ProxyPixel::~ProxyPixel. Да, основное изображение будет временно не синхронизировано с изменением размера прокси-пикселя, но оно будет более эффективным. Разумный компромисс.

Answer 2

Я мог бы использовать методы доступа в структуре пикселей вместо простых полей и дать ссылку на своего владельца, чтобы позвонить домой. Это, однако, означает, что если пользователь изменил R, G, B и A, я бы четыре раза преобразовал пиксель в формат пикселя растрового изображения и записывал его в память 4 раза.

Это подталкивает закон деметатора (пиксель не должен изменять растровое изображение, чтобы установить его собственное значение); Вы не должны этого делать.

Я могу вернуть ссылку на пиксель из итератора и предоставить ему метод Update(), который необходимо вызвать, если пиксель был изменен. Это было бы неинтуитивно понятным, и пользователи-пользователи не захотели бы вызвать Update.

Это немного плохой интерфейс, так как это будет сложно использовать правильно, не забывая ничего. Это также нарушает прокладку demeter (вы не должны обновлять растровое изображение через пиксель).

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

Не делайте этого; это нарушает принцип наименьшего удивления.

Рассмотрите возможность создания пикселя независимо от растрового изображения (то есть пиксель не знает, что такое растровое изображение).

Вы должны иметь возможность устанавливать (действительные) значения в пиксель легко (с помощью аксессуаров для полей или Update(R, G, B, A) или аналогичных) и иметь растровое изображение, знать, что такое пиксель, и как обновлять себя из пикселей, одним (или более) из них:

void Bitmap::Update(int x, int y, const Pixel& p); 
void Bitmap::Fill(const Pixel& p); 
void Bitmap::SetRange(SomeRangeObject r, const Pixel& p); 

Таким образом, операция обновления на пикселах потребуется следующие шаги:

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

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

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

Answer 3

Элементы структуры пикселя могут быть реализованы как свойства.

Это позволит вам писать такие вещи, как

iter->r = 0; 

Это не позволит вам отправить пиксель-структуру для функций, которые ожидать, что это будет «straigtforward»

Реализация имущества в С ++ легко, смотри, например here

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