Безопасно ли увеличивать итератор внутри при использовании его в качестве аргумента?

В настоящее время я пытаюсь стереть последовательность итераторов из набора, однако стандартная библиотека GCC, похоже, не работает, потому что std :: set :: erase (итератор) должен возвращать итератор (следующий итератор), однако в GCC он возвращает void (что стандартно?)

В любом случае я хочу написать:

myIter = mySet.erase(myIter);

Но GCC это не нравится ... Так безопасно ли писать это вместо этого?

mySet.erase(myIter++);

Изменить: И да, я проверяю mySet.end ();


person Robert Gould    schedule 02.10.2008    source источник


Ответы (2)


Нет проблем с

mySet.erase(myIter++);

Порядок работы четко определен: myIter копируется в myTempIter, myIter увеличивается на единицу, а myTempIter затем передается методу стирания.

Для Грега и Марка: нет, оператор ++ не может выполнять операции после вызова стирания. По определению, erase () вызывается после возврата оператора ++.

person Camille    schedule 02.10.2008
comment
То, что вы говорите, верно только потому, что оператор ++ был переопределен классами. Для POD оператор фактически вызывается после строки! - person PierreBdR; 02.10.2008
comment
Да, это интересное замечание. И все дело в том, что порядок операций не имеет значения для типов POD, поскольку приращение всегда четко определено. Что ж, вы всегда можете представить себе странные случаи, когда метод имеет некоторый доступ к ссылке на POD-переменную, но это не рекомендуется. - person Camille; 02.10.2008

Сначала перечитайте стандарт, и вы увидите, что прототип метода set :: erase:

void erase(iterator position);

Однако ассоциативные контейнеры в STL являются «стабильными», поскольку стирание элемента не влияет на итераторы других элементов. Это означает, что допустима следующая строка:

iterator to_erase = myIter++;
mySet.erase(to_erase);
// Now myIter is still on the next element
person PierreBdR    schedule 02.10.2008
comment
Особая благодарность за то, что вы вспомнили о том, что у наборов нет итераторов произвольного доступа! - person Robert Gould; 02.10.2008