Есть итератор. С переходом на новую студию возникла проблема сравнения итератора с NULL. Нужна какой-то аналог NULL .

что значит сравнить с NULL? в чем собственно проблема? может тебе надо сравнить с концом интервала?

то есть например сделать запись вида

if (m_IterSelected!=NULL)
{
};

m_IterSelected это итератор на элемент в одном из списков, либо он должен быть равен чему-то типа NULL , если не один элемент не выделен.

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

мягко говоря, это не область применения С++ итераторов.

сравнивай с правильным.

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

согласен. Ерунда какая-то. Если итератор не инициализирован, то там в общем виде что попало.

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

переписать правильно.

ну так показывай как там у тебя сделано. Может и можно что-то придумать...

Допустим есть два списка  list<int> list1  и list<int> list2

и итератор вида

list<int>::iterator m_IterSelected;

m_IterSelected может указывать как на элементы списка list1 так и на эл-ты list2 , либо вообще никуда не указывать


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

Добавлено через 3 минуты
Fazil6 
а какая разница ? итераторы из разных списков не могут быть равны по определению. Или может тебе надо сравнивать значение, на которое этот итератор указывает?


Проблема в том, что при сравнении итераторов из разных списков программа вылетает, вместо того, чтобы вернуть "не равны"!

указатель на элемент тебя спасет.

Как мне тогда перемещаться по STLевскому списку?

#define _SECURE_SCL 0
вырубает checked итераторы

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

Это сообщение отредактировал(а) UnrealMan - 18.9.2007, 17:06

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

Добавлено через 11 минут и 28 секунд
#define _SECURE_SCL 0 

вроде бы убирает только ворнинги - вылеты программы не исчезают!

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

Введи вместо итератора 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