green Да точно это #include <iostream> до #define _SECURE_SCL FALSE картину портило - но всё равно гибкости маловато - получается включать/выключать эту проверку по мере её реальной необходимости нельзя - только для всего модуля и для всех stl объектов раз и навсегда.
green Соглашусь, иногда полезная фича. Но всё же я пока не решусь такое использовать, заюзаю присваивание в цикле. Y_Mur А как иначе добиться максимальной эффективности?
Booster Имхо ничего не мешает определять макрос-флажок типа #define _SECURE_SCL FALSE/TRUE в любом месте программы так чтобы он действовал только на нужный блок методов объекта, до следующего такого макроса и не вижу причин по которым к одним и тем же данным объекта нельзя было бы обращаться как с проверкой так и без. А так получается что при включенной проверке временно отключить её можно только путём обращения к вектору как к массиву. К тому же если проверка нужна например в iostream, то и в vector её не отключишь - где же тут максимальная эффективность? Хотя всё равно спасибо green за подсказку - в большинстве случаев действительно ничего не мешает отключить её раз и навсегда.
Книжки читать пробовали? Настоятельно рекомендую: C++ Standard Library - A Tutorial and Reference по теме invalidate iterators. Ну если на стандарт потянуло, то открываем ISO 14882-1998, смотрим 23.2.4.3 Vector modifiers и 23.2.2.3 List modifiers.
Из требований к random access iterator. Ты давно вырос из подобных вопросов, не заставляй людей за тебя искать в стандарте ) Всё равно такой код вряд ли пишут, индексы безопаснее... Проверка выполняется только в at().
Гарантирует, но эта гарантия распространяется только на итераторы, которые ссылаются на элементы, находящие _до_ точки вставки. Поэтому вызов функций 'std::vector<T>::push_back' (ее семантика определена как 'vec.insert(vec.end(), value)' и любых форм 'insert' инвалирует итератор, который до этого возвращала функция 'end()'. Наличие или отсутствие реаллокации на этот аспект поведения никак не влияет.
Наличие признаков, по которым был сделан такой вывод ("ставший валидным") - это результат undefined behaviour.
Народ, я не пойму, а что собственно требуется? Может этого можно добиться и без жестокого ковыряния в деталях реализации?