Введи вместо итератора boost::optional <iterator> - либо есть, либо нет.
Если буст не используешь - нарисуй что-то похожее: грубо говоря, pair<iterator,bool> + простейшие методы: get, set, reset и isnull. Вместо get можно написать оператор разыменования или оператор(), или даже оператор приведения, вместо set - оператор =. Это чтобы меньше кода править. Самое главное - если просто изменишь тип переменной m_IterSelected на этот optional, компилятор поможет выловить все вхождения и поправить. Если справишься за полчаса, значит, обошелся малой кровью. Если больше - все равно время конечно, но зато запомнишь и больше так не будешь!  
Вообще, хранить в классе итераторы - дурная привычка. Итератор, по определению, штука временная.

Ну, оператор разыменования написать можно и даже нужно. И стрелку в добавок к нему. А функциональный оператор тут совсем не к месту. Оператор преобразования можно сделать разве что для получения какого-нибудь псевдо-bool объекта (например, указателя на член класса).

Нет, я имела в виду прежде всего цель "малой кровью": оператор приведения (к типу итератора, разумеется) и оператор = позволят сохранить старый код (т.е. он будет компилироваться и работать). Если добавить еще оператор == (int) или (void*) или (лучше) сделать конструктор, который будет принимать 0 (т.е. int\void*) в качестве параметра, да еще + к этому операторы ==\!=, это позволит сохранить в рабочем виде практически весь код. Главное - не перестараться, и со временем все-таки переписать это дело...

В первую очередь, нужен конструктор, принимающий итератор. Если делать ещё и оператор преобразования к итератору, то перегрузка == и != просто необходима. Но проблема не в этом, а в том, что увеличивается вероятность пропустить какую-нибудь переменную-итератор, которую следует заменить на обёртку. IMHO, получение итератора лучше сделать явным.


Я бы выбрал не int и не void*, а указатель на член какого-нибудь внутреннего класса.

А почему бы, действительно, не сделать, как сказали выше?? Завести константный list3 пустой. и писать 

ведь итератор end определен и для пустого списка, или нет??

Ну, определён, и что дальше?

ну иметь типа нулевой элемент, когда итератор ни на что не указывает, то направлять его на конец нулевого списка, потом проверять это. Это не подходит разве?

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

Это сообщение отредактировал(а) UnrealMan - 22.9.2007, 13:30