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

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

Кто сказал?

я, для 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ага )

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

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

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

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

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

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

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

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

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

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

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

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

и автора )

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

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

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

полная копия

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

ага

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Товарищи.

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

А кто адрес обновит?

https://ideone.com/O6hc72 Кем будет обновлён адрес на новый вектор у итератора?

А кто адрес обновит?

адрес кого? )