Наверно я не понимаю как оно работает.

нужно почитать про устройство stl :)

Возможно поэтому у меня иногда ломается программа

В зависимости от размера массива

Кто сказал?

я, для bool точно нету xor оператора

я, для bool точно нету xor оператора

>>> True ^ True False

В зависимости от размера массива

не всегда итераторы инвалидируются при вставке, есть гарантии отсутсвия инвалидации итераторов у связных списков при некоторых вставках, у вектора при вставке в конец при отсутствии реалокации и т.п. Всё прописано в стандарте, но на это поведение лучше не закладываться

>>> True ^ True False

да, но xor оператора нет, а and, or, not есть. Это я имел ввиду

да, но xor оператора нет, а and, or, not есть. Это я имел ввиду

Его легко реализовать при помощи уже существующих

да, но xor оператора нет, а and, or, not есть. Это я имел ввиду

не понял, а что за оператор выше?

В логических выражениях xor довольно редко нужен

не всегда итераторы инвалидируются при вставке, есть гарантии отсутсвия инвалидации итераторов у связных списков при некоторых вставках, у вектора при вставке в конец при отсутствии реалокации и т.п. Всё прописано в стандарте, но на это поведение лучше не закладываться

Мы говорим именно про вектор и про реаллокацию

Храним ссылку на вектор и индекс, тут нечего показывать

Проблема, что ссылка инвалидируется тоже

Проблема, что ссылка инвалидируется тоже

Ссылка на сам объект вектора не инвалидируется

Так как под капотом это всё равно указатель

Поэтому привыкайте юзать ranges в виде range_v3 :) правда ту же stl всё же нужно проштудировать перед использованием более высокоуровневых аналогов

Я такие итераторы для дека писал, проблем не было

Ссылка на сам объект вектора не инвалидируется

кто то только что пристрелился ?

кто то только что пристрелился ?

?

сеть лагает, уже написали что ссылка по сути тоже указатель

А какая разница?

Ссылка на сам объект вектора не инвалидируется

Извините, но я не верю в это. Можно ссылку для Просвещения?

обьекты будут перемещены

у них будут новые адреса

обьекты будут перемещены

Объекты будут, вектор не будет

ссылка будет на старые адреса

ссылка будет на старые адреса

Стой

аа ссылка на сам вектор

аа ссылка на сам вектор

Да

Я сейчас кое-что гляну

вообще, вроде как ничто не мешает сделать свой итератор по вектору который работает по принципу ссылка на вектор + offset

кто захочет платить за все вытекающие - пожалуйста

итераторы такие как они есть из основной идеалогии С++ - не платить за то что тебе ненужно

итераторы такие как они есть из основной идеалогии С++ - не платить за то что тебе ненужно

слабый какой-то аргумент

итераторы такие как они есть из основной идеалогии С++ - не платить за то что тебе ненужно

наоборот же

вообще, вроде как ничто не мешает сделать свой итератор по вектору который работает по принципу ссылка на вектор + offset

RandomAccessIterator у std::vector так и работает, причем у некоторых стандартных алгоритмов имеются соответствующие перегрузки на этот tag

обычно, использование указателя на первый элемент вектора - быстрее, чем итераторы

If a reallocation happens, all iterators, pointers and references related to the container are invalidated. Otherwise, only those pointing to position and beyond are invalidated, with all iterators, pointers and references to elements before position guaranteed to keep referring to the same elements they were referring to before the call.

итераторы такие как они есть из основной идеалогии С++ - не платить за то что тебе ненужно

Таки list::splice от 3 итераторов за О(n) работает, так что аргумент сомнительный

Ну вот где из этого вытекает, что итератор на сам вектор не инвалидируется - непонятно

Я не могу найти подтверждение слов Дениса

обычно, использование указателя на первый элемент вектора - быстрее, чем итераторы

очень очень сомнительно

Ну вот где из этого вытекает, что итератор на сам вектор не инвалидируется - непонятно

Нет итератора на вектор, есть сам вектор, который мы объявили, например, на стеке

Нет итератора на вектор, есть сам вектор, который мы объявили, например, на стеке

да, и на него ты держишь внутри итератора ссылку

Да, держу. Он же не может со стека куда-то убежать?

я прекрасно понимаю твою мысль, пойми) Я не могу найти подстверждения твоим словам

Подтверждение того, что объект не может сам изменить свой адрес?

Типа delete this; this = new vector()

Это даже не скомпилится

Типа delete this; this = new vector()

именно

очень очень сомнительно

ну раз сомнительно - смотрите исходники

если _ITERATOR_DEBUG_LEVEL стоит дефолтный - всякие ненужные проверки

если _ITERATOR_DEBUG_LEVEL стоит дефолтный - всякие ненужные проверки

Сейчас сравню)

RandomAccessIterator у std::vector так и работает, причем у некоторых стандартных алгоритмов имеются соответствующие перегрузки на этот tag

ты уверен что он хранит адрес самого вектора и текущую позицию в качестве size_t ?

ты уверен что он хранит адрес самого вектора и текущую позицию в качестве size_t ?

причем здесь адрес самого вектора?

при том что обсуждался вариант итератора который хранит именно адрес самого вектора и индекс в качестве числа

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

при том что обсуждался вариант итератора который хранит именно адрес самого вектора и индекс в качестве числа

адрес вектора никак не коррелирует с адресом начала данных, который можно получить через vector::data()

и тогда типо итератор не инвалидируется

ценой конечно косвенных обращений

адрес вектора никак не коррелирует с адресом начала данных, который можно получить через vector::data()

именно. Но по адресу самого векотора мы получаем обьект. Потом из обьекта мы вытягиваем data(), поотом прибавляем offset

ага )

при том что обсуждался вариант итератора который хранит именно адрес самого вектора и индекс в качестве числа

опять же, посмотрите исходники. итератор "из коробки" - запоминает прямо указатель на сами данные

именно. Но по адресу самого векотора мы получаем обьект. Потом из обьекта мы вытягиваем data(), поотом прибавляем offset

Итератор ничего не должен знать про контейнер

по описанной вами схеме - да, работало бы.

опять же, посмотрите исходники. итератор "из коробки" - запоминает прямо указатель на сами данные

сей факт никто не оспаривает

по описанной вами схеме - да, работало бы.

это не моя схема ) и я даже не поддерживаю её

Итератор ничего не должен знать про контейнер

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

ERROR: S client not available

А почему они не могли сделать итераторы, не ломающиеся при реаллокации?

Казалось бы. это несложно

Храним ссылку на вектор и индекс, тут нечего показывать

это для тех кто потерял нить

и автора )

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

а если вы вектор передали в другую функцию? кто будет обновлять ссылку на вектор у итератора?

А почему они не могли сделать итераторы, не ломающиеся при реаллокации?

потому что это "индекс" получится

полная копия

примерно как доступ по vec[n]

ага

а если вы вектор передали в другую функцию? кто будет обновлять ссылку на вектор у итератора?

не совсем понял.

перемещение вектора это уже другая история

не совсем понял.

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

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

в таком случае итератор инвалидируется но вариаций инвалидации становится куда меньше

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

ссылки* Но это не так важно. А зачем её обновлять при копировании? При копировании итераторы всё равно будут указывать на исходный вектор

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

Или я снова не так понимаю?

сейчас если переместить вектор то итераторы не инвалидируются

но нафига оно мне надо

ссылки* Но это не так важно. А зачем её обновлять при копировании? При копировании итераторы всё равно будут указывать на исходный вектор

Так вектор зачастую на стеке создаётся. Ваша ссылка на вектор будет указывать на другой стекфрейм и не факт, что она продолжает быть валидной

Так, смотрите:

Так вектор зачастую на стеке создаётся. Ваша ссылка на вектор будет указывать на другой стекфрейм и не факт, что она продолжает быть валидной

а нафига мне итераторы после перемещения вектора?

я что их вместе с ним буду перемещать?

std::vector<int> vec; auto it = vec.begin(); auto vec2 = vec; И какое отношение имеет итератор it к vec2?

std::vector<int> vec; auto it = vec.begin(); auto vec2 = vec; И какое отношение имеет итератор it к vec2?

сейчас я покажу свою мысль

Хм, такой сценарий, у меня два итератора, я добавляю в вектор значения и он реаллоцируется

Инвалидируем итераторы?

Инвалидируем итераторы?

В лучшем случае нет, в худшем да

если в памяти есть место довыделить память, то итераторами можно будет пользоваться

если нет, то нельзя

но вообще лучше просто всегда считать что они инвалидируются

Инвалидируем итераторы?

в теккщих итераторах - да, в предлагаемых - нет

Товарищи.