вот есть у нас объект вектора.
вот есть у нас объект итератора для этого вектора.
и вот мы сделали move() для вектора. в каком состоянии итаратор?
казалось бы, итератор для вектора — просто указатель. и, если мы не переаллоцируем вектор — указатель быдет указывать в прежний адрес.
но, есть дебажные итераторы(говорю о libstdc++) которые не просто указатель. я, по правде сказать, не заглядывал им внтурь, наверняка они все так же хранят указатель.
вопрос в том, есть ли какие-то гарантии того, что итераторы остаются валидными при перемещении(move) контейнера? (по логике — должны быть)
спасибо.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>вопрос в том, есть ли какие-то гарантии того, что итераторы остаются валидными при перемещении(move) контейнера? (по логике — должны быть)
Вряд ли. Допустим, итератор хранит указатель на контейнер его породивший...
After container move construction (overload (6)), references, pointers, and iterators (other than the end iterator) to other remain valid, but refer to elements that are now in *this. The current standard makes this guarantee via the blanket statement in §23.2.1[container.requirements.general]/12, and a more direct guarantee is under consideration via LWG 2321.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
AD>>Вряд ли. Допустим, итератор хранит указатель на контейнер его породивший... X>ну допустим. и как это мешает?
Судя по тобой приведенной цитате, уже никак.
X>move-ctor не выделяет пумять, значит он использует от породившего.
То есть, итератор не может ссылаться на внутренние данные объекта. Например, std::string с фиксированным in-place буфером.
Но для std::string и нет гарантий переезда итераторов после move.
Здравствуйте, andrey.desman, Вы писали:
AD>То есть, итератор не может ссылаться на внутренние данные объекта.
да, иначе он станет невалидным.
AD>Например, std::string с фиксированным in-place буфером. AD>Но для std::string и нет гарантий переезда итераторов после move.
я никогда не задумывался об этом, но да, in-place буфер получается автоматический массив член класса, и если std::string создан на стеке — его не перенести. но даже если std::string создан в куче — его тоже не перенести, ибо в С++ нет возможности по адресу память понять, это стек или куча...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
