Как написать второй operator= в C++?

Question

[Mercury13]

В дополнение к operator= хочу сделать такой шаблон:

template <class T>
void stealDataFrom(T& to, T& from);

У некоторых простеньких типов этот stealDataFrom очевиден.

class OverrideableInt {
  optional<int> autoValue, overrideValue;  // на самом деле чуть не так, но очень похоже
}

template <>
void stealDataFrom(OverrideableInt& to, OverrideableInt& from) {
  to.overrideValue = from.overrideValue;
  // autoValue не трогаем!
}

Пока нормально. А теперь возьмём какой-нибудь сложный тип.

struct Item {
  OverrideableInt weight, volume, price;
}

Как этому Item’у автоматически прописать stealDataFrom?

Потому я и назвал это «второй operator=»: Си++ напишет op= сам, а мне надо что-то похожее для другой функции.

Comments

[Евгений Шатунов]

Mercury13 , слушай, а чего бы просто не использовать семантику перемещения?
Сейчас stealDataFrom у тебя ничего не steal, т.к. он вызывает оператор копирования.

Вот если бы там вызывался оператор перемещения (т.е.

OverrideableInt& OverrideableInt::operator = ( OverrideableInt&& right )

), то это был бы именно steal. Но и в таком случае steal лучше заменить на move чтобы не грузить пользователей твоего кода синонимами.

А в целом еще было бы интересно понять, чем такая функция может помочь. Какую конкретную задачу она призвана решать.

[Mercury13]

Евгений Шатунов,
Это НЕ семантика перемещения: смысл семантики перемещения в том, что мы создаём идентичный объект, но при этом можем выпотрошить исходный. Исходный мы действительно можем выпотрошить, но to не будет идентичным!! И vector<OverrideableInt>, также полагающийся на перемещение, откажет к чертям!

[Евгений Шатунов]

Mercury13, погоди, а что такое "создаём идентичный объект"?
Почему после перемещения from в to последний не будет идентичен?
А почему вектор откажет?

Семантика перемещения говорит переместить состояние правого операнда в левый, оставив правый после перемещения в консистентном состоянии и сохраняя инвариант своего типа.

Я, в таком случае, совсем не понимаю смысл слова steal. :)
Steal - украсть. Украсть - забрать что-то у кого-то. Забирая что-то, мы это что-то куда-то перемещаем. Т.е. мы выполняем семантику перемещения, но называем это все кражей. Так еще куда ни шло, хоть вводит еще один синоним уже понятной операции. Но вот если steal ничего не крадет, то это уже очень странно.

[Mercury13]

Евгений Шатунов,
Да, операция перемещения обязана оставить объект в адекватном состоянии. Но имеет право выпотрошить из него любые данные.

Задача более высокого уровня. Мы импортируем кучу данных из БД (и время от времени импортируем снова). AutoValue импортирован, overrideValue введён руками и его терять НЕЛЬЗЯ. При импорте бывают ошибки, и чтобы при аварии результат наших действий не пришлось болезненно откатывать, мы придумали такое. Мы создаём второй объект, и если импорт из БД удался — мы тянем из исходного, во-первых, те периоды данных, за которыми в БД не лезли. Во-вторых, всё, что ввели вручную. Это и есть stealDataFrom.

Этот метод железобетонно надёжен касательно ошибок БД, но потребляет много памяти и багоопасен. С памятью чёрт с ним, ВОПРОС: что компилятор может сделать для нас?

[Евгений Шатунов]

Mercury13, тогда, минимально, это операция применения (apply) или, что ближе всего, операция переопределения - override.
Смотри как много непонимания создается от использования всего одного слова не по месту. :)

По своей сути компилятор автоматом для тебя только операторы копирования и перемещения может сделать. Остальное тебе надо ему объяснить.
У тебя там class OverrideableInt, поле overrideValue является приватным. Значит тебе не просто саму stealDataFrom надо написать, но еще и объявление дружественности написать.

Кажется я начинаю понимать суть твоей затеи. Похоже что таких OverrideableXYN у тебя много, они все разные и являются составными частями модели записи в базе. Потом ты хочешь из одной записи в базе перетянуть только оверрайды значений.
У меня есть архитектурное решение для тебя. Коротко - это тебе для сложных случаев надо создать список посещения и, собственно, steal выполнять через визитера по двум спискам. Вроде такого.

dest_record.Visit( source_record, ApplyOverriddenValue );

Могу расписать немного подробнее, если надо.

[Mercury13]

Евгений Шатунов, Нет, не скрытое. А если и скрытое — вопросов не будет.
Задачу-то я понял, но вопрос именно в том, чтобы этих обходчиков не писать собственными силами хотя бы в простых случаях.

Answer 1

[tsarevfs]

1. Мне кажется steal не очень удачное название, так как может запутать. В C++ есть присваивание (assignment) где правый аргумент сохраняет значение и перемещение(move) где правый аргумент передает значение левому и теряет собственное (например строка становится пустой).
Ваш код выглядит как assingn. В этом случае правый аргумент from правильнее сделать константным, так как менять его вы не планируете.

void assignDataFrom(OverrideableInt& to, const OverrideableInt& from)

2. >Как этому Item’у автоматически прописать stealDataFrom?
Автоматически генерировать код в C++ пока нельзя. Reflection ожидается в будующих стандартах, но пока он есть только в виде эксперементальных реализаций.
3. Оператор присваивания будет сгенерирован по умолчанию, если не определять его самостоятельно. Он будет использовать операторы присваивания всех нестатических полей класса. Получается для Item сгенерированный по умолчанию оператор сделает то, что вам нужно, если для OverrideableInt он определен правильно.
4. assignDataFrom может использовать этот сгенерированный оператор.

void assignDataFrom(Item& to, const Item& from) {
    to = from;
}

Так вы сможете написать обобщенную шаблонную функцию.

Comments

[Mercury13]

1. Это НЕ ПОЛНОЕ присваивание: autoValue оставляем как было, а оverrideValue тянем. Потому не assign. Мало того, from идёт на уничтожение и если его можно выпотрошить — он будет выпотрошен.
2. Огромное количество вещей Си++ полагаются на op= (например, std::vector) и потому op= нужен либо нормальный, либо вообще никакого.

[tsarevfs]

Mercury13, В целом вы правы. Но оператор присваивания не обязан делать полную копию всех полей. Если получающийся объект со стороны выглядит эквивалентным, то все ок. Например если объект закешировал результат каких-то вычислений, кеш может быть отброшен. Или тот же std::vector после копирования может иметь меньший capacity, если он был слишком большой. Или copy on write для QString.
Если это не ваш случай, то универсального решения нет. Очень похожая проблема возникает при сериализации. Я видел много разных костылей на макросах и даже внешние кодогенераторы (как делает moc в Qt, например для QProperty). Но жизнь это упрощает далеко не всегда.