SS
все равно ведь деструкторы нужно вызвать при resize() (если < size), тот же самый эффект, как и у erase получается
Size: a a a
2021 July 06
O
Именно, об инвалидации следующих позиций. Этого достаточно, чтобы трактовать как гарантию отсутствия инвалидации предыдущих. Возможно ли гарантировать отсутствие инвалидации при реалокации?
VS
если, как вы говорите,
resize() может сделать реаллокацию, то инвалидировано будет все, а не только с текущей позиции и до концаshrink_to_fit() и тот инвалидирует всеTS
а если рассмотреть какую-то систему "сферический конь в вакууме", на которой возможно совершать реалокацию в меньшую сторону, просто высвобождая память неиспользуемых элементов, при этом не затрагивать ту память, которая была выделена под имеющиеся элементы?
SS
но ведь задача стандарта как раз найти общее поведение, которое не будет противоречить большинству систем. Таким образом, даже если на описанной вами системе такое возможно, то мы все равно будем считать, что они инвалидировались, так как нам важна переносимость
IZ
Так это на любой системе можно, вот хоть прямо на Винде. Тем более что весьма вероятно что новый кусок памяти будет другим, и старый можно будет использовать полностью
VS
да, такое теоретически возможно, но я не вижу, чтобы стандарт требовал существование такого механизма от реализаций (либо я не нахожу, чтобы требовал).
зато нахожу еще одно упоминание реаллокации, которая все инвалидирует
поэтому если такая чудесная реаллокация и будет выполнена реализацией, она не будет реаллокацией в терминах стандарта, то есть не будет ничего инвалидировать
зато нахожу еще одно упоминание реаллокации, которая все инвалидирует
поэтому если такая чудесная реаллокация и будет выполнена реализацией, она не будет реаллокацией в терминах стандарта, то есть не будет ничего инвалидировать
VS
и еще встает вопрос, а чего это вдруг
size() меняет емкость контейнера. такие случаи тоже явно прописаны в стандартеIZ
REsize ?
O
>> она не будет реаллокацией в терминах стандартаЯ не уверен, но означает ли инвалидация, что адреса элементов будут буквально изменены? Если нет – инвалидация у нас всё-равно случалась, хотя адреса и не изменились – для нас это ничего не значит, мы всё равно не имеем права обращаться к данным по инвалидированным указателям из-за UB. А если обратимся и обнаружим, что элемент на месте – ничего страшного, ожидаемое поведение – тоже одно из проявлений UB
VS
так и
size() не имеет отношения к емкости. почему resize() должен? когда есть reserve() и shrink_to_fit()IZ
Ну, имеет...
VS
size() <= capacity() это не то, о чем мы тут говорим, как мне видитсяVS
я думаю, что она значит, что они могут измениться, потому что никто не требует от реализаций расширять текущий storage
если адреса не поменялись и мы пользуемся старыми указателями и ссылками, то это даже не UB благодаря transparently replaceable, если я ничего не упускаю
если адреса не поменялись и мы пользуемся старыми указателями и ссылками, то это даже не UB благодаря transparently replaceable, если я ничего не упускаю
С
Ребят,
А можно ли задать одинаковое имя для члена класса и для входящего параметра метода этого класса? Области видимости разные же?
А можно ли задать одинаковое имя для члена класса и для входящего параметра метода этого класса? Области видимости разные же?
K
проверить 2 секунды
С
Д я не дома, проверил бы уже ☹️
K
в конструктор можно
Б
Да
С
Значит в метод тоже можно, благодарю, видимо нам запрещает это фреймворк