Size: a a a

2020 September 19

D

Danya in pro.cxx
Anatoly Tomilov
В агрегате есть поле тривиального типа и есть поля нетривиального. Когда я сделаю перемещение, гарантируется ли, что значение поля тривиального типа останется прежним? Пример: std::pair<int, std::vector<int>> x{123, {1, 2, 3}}; auto y = std::move(x); assert(x.first == 123);.
Нельзя надеяться на это
x находится в moved-from state и вряд ли им вообще можно пользоваться, кроме вызова деструктора
источник

AT

Anatoly Tomilov in pro.cxx
Danya
Нельзя надеяться на это
x находится в moved-from state и вряд ли им вообще можно пользоваться, кроме вызова деструктора
подобные выкладки я читал. Предположить, что они верны и в данном случае, я могу. Но пример более хитрый, т.к. очевидно, что в реальности чтобы испортить x.first нужны от компилятора какие-то дополнительные и, кажущиеся лишними, действия. Вряд ли он их будет совершать. Отражено ли это в стандарте явно — это меня интересует.
источник

m

magras in pro.cxx
Anatoly Tomilov
В агрегате есть поле тривиального типа и есть поля нетривиального. Когда я сделаю перемещение, гарантируется ли, что значение поля тривиального типа останется прежним? Пример: std::pair<int, std::vector<int>> x{123, {1, 2, 3}}; auto y = std::move(x); assert(x.first == 123);.
Мне кажется, что да, это гарантированно, так как конструктор выполнит direct-initialization: https://eel.is/c++draft/class.copy.ctor#14.3

Но я не настоящий сварщик.
источник

m

magras in pro.cxx
Danya
Нельзя надеяться на это
x находится в moved-from state и вряд ли им вообще можно пользоваться, кроме вызова деструктора
Это касается только типов из стандартной библиотеки. Для своих типов семантика может быть какой угодно. Но, конечно, хорошая практика поддерживать стандартную семантику.
источник

D

Danya in pro.cxx
magras
Это касается только типов из стандартной библиотеки. Для своих типов семантика может быть какой угодно. Но, конечно, хорошая практика поддерживать стандартную семантику.
Это понятно
источник

AT

Anatoly Tomilov in pro.cxx
magras
Это касается только типов из стандартной библиотеки. Для своих типов семантика может быть какой угодно. Но, конечно, хорошая практика поддерживать стандартную семантику.
у агрегата нет user-defined конструктора и оператора перемещения
источник

AT

Anatoly Tomilov in pro.cxx
magras
Мне кажется, что да, это гарантированно, так как конструктор выполнит direct-initialization: https://eel.is/c++draft/class.copy.ctor#14.3

Но я не настоящий сварщик.
похоже на объяснение
источник

ПК

Побитый Кирпич... in pro.cxx
Danya
Нельзя надеяться на это
x находится в moved-from state и вряд ли им вообще можно пользоваться, кроме вызова деструктора
Присваивать можно
источник

OZ

Olzhas Zhumabek in pro.cxx
хорошо бы если стандарт объяснил что такое unspecified, but valid (not undefined?) state
источник

ПК

Побитый Кирпич... in pro.cxx
Olzhas Zhumabek
хорошо бы если стандарт объяснил что такое unspecified, but valid (not undefined?) state
А что непонятного?
источник

ПК

Побитый Кирпич... in pro.cxx
Это значит "любое валидное"
источник

A

Alex Ф-ф-фэils!🌠︙... in pro.cxx
N 2
в c++ никакими костылями нельзя сделать extension метод? Точнее даже не экстншн метод, а в плане синтаксиса чтобы после имени объекта вызывать функцию которая что-то делает
CRTP спасёт, см там буст-лог например, там автор базовый логгер фарширует фичами (северити, фасилити) , и их методы расширяют интерфейс
источник

OZ

Olzhas Zhumabek in pro.cxx
Побитый Кирпич
Это значит "любое валидное"
насколько я понял типы сами могут выбрать в каком состоянии оставлять, но самое частое что я видел это свап для мув присваивания, и свап с дефолт созданным объектом для мув конструктора. Было бы хорошо иметь список минимальных операции которые разрешены на объекте (я видел мув конструкторы после которых трогать вообще нельзя)
источник

ПК

Побитый Кирпич... in pro.cxx
Olzhas Zhumabek
насколько я понял типы сами могут выбрать в каком состоянии оставлять, но самое частое что я видел это свап для мув присваивания, и свап с дефолт созданным объектом для мув конструктора. Было бы хорошо иметь список минимальных операции которые разрешены на объекте (я видел мув конструкторы после которых трогать вообще нельзя)
Любые операции можно. Просто если у операции есть предусловия на this, но результат операции unspecified (в том числе может быть и ub)
источник

ПК

Побитый Кирпич... in pro.cxx
Например можно звать clear() для вектора, но нельзя pop_back()
источник

ПК

Побитый Кирпич... in pro.cxx
Вернее pop_back можно, но результат unspecified
источник

OZ

Olzhas Zhumabek in pro.cxx
мне кажется проблема в слишком сильном фокусе на xvalue классе значении. Иногда люди не хотят создавать больше переменных чем надо, и переиспользуют
источник

ПК

Побитый Кирпич... in pro.cxx
Olzhas Zhumabek
мне кажется проблема в слишком сильном фокусе на xvalue классе значении. Иногда люди не хотят создавать больше переменных чем надо, и переиспользуют
Дак какая проблема то?
источник

OZ

Olzhas Zhumabek in pro.cxx
например вне цикла ты создаешь объект, в цикле скажем заполняешь как то, потом делаешь std::move(). Потом объект дальше живет для следующей итерации
источник

OZ

Olzhas Zhumabek in pro.cxx
я про случаи когда moved from объект дальше используется и по достаточно приемлемым причинам
источник