Своп предполагает, что присваивание происходит сразу и слева на право, и наоборот, const запрещает всякое изменение правого операнда. Даже если эта пакость скомпилится, первая мысль при чтении такого безобразия будет или прямо противоположной, или, что опретор присваивания меняет оба операнда. А на, чтоб разобраться, уйдёт время. Убирать const - ещё хуже: оператор именно поменяет местами свои операнды, чего делать не должен.


Это сообщение отредактировал(а) ТарасАтавин - 18.9.2013, 14:37

ТарасАтавин, вообще-то, это классика как нужно писать оператор присваивания, чтобы делать его "безопасным для исключений"(тут с термином мог ошибиться, не помню как у Саттера там классификация идет). Более того, таким образом мы гарантируем, что и копирующий конструктор и оператор присваивания у нас делают одно и тоже.
А если конструкция не привычна для восприятия, то нужно привыкать.

А как можно умудриться сделать опасный оператор присваивания? Кроме MyClass& MyClass::operator=(MyClass &other)
{
   MyClass(other).swap(*this);
}[/code], конечно. Кстати, оператор присваивания обязан возвращать ссылку на this, так что ваша "классика" страдает грубым нарушением стандарта.

Это сообщение отредактировал(а) ТарасАтавин - 18.9.2013, 18:58

правый операнд это other ? больше ничего с конст не нахожу.. 
и где ктор его меняет     


  не дай бог попасть кому-нибудь к врачу с таким же 13 летним опытом...

Добавлено через 2 минуты и 9 секунд

а как насчет того, чтоб читать между строк  ? 
эта строчка с возвращением this никакой роли не влияет, потом в форумных примерах на коленке может быть безболезнено упущена  

Добавлено через 6 минут и 49 секунд
  
ТарасАтавин, был тут на форуме уже докторКтоТоТам, тоже себя в грудь бил и кричал громче всех.. 
еще и книжки писал.. Вы еще не пробовали ? что ж ценный опыт пропадает ... 

немало ИТшных форумов, где он был заблокирован...   

ТарасАтавин, расскажи, что делает конструкция MyClass(*this)?

вообще-то любая функция, которая при возникновении исключений гарантирует отсутствие утечки ресурсов уже сама по себе является exception safe, так-как соответствует базовому правилу безопасности исключений Абрахамса (раз уж вспомнили Сатера, то Сатер в своей книге цитировал именно его). А сохранение состояния программы при возникновении исключений является строгой гарантией, которую можно обеспечивать а можно и нет, зависит от программы.

Да, а что если это не тривиальный объект с двумя целочисленными типами а скажем что нибудь посложнее..ну например вот такой класс

Что буде на 21-ой строке, если он содержит мусор?

Это сообщение отредактировал(а) azesmcar - 24.9.2013, 16:04

swap.

Добавлено @ 18:28
Даже если return *this спрятано внутри swap, реализация оператора присваивания не содержит этой операции, а по стандарту должна.

Добавлено @ 18:31
И это говорит человек, игнорирующий return *this. Ну ка как должен повести себя  при ? По идее компилятор должен ругнуться, в то время как для всех встроенных типов это вполне валидная строка и  сохраняет её валидность. То есть пропущенный return *this или вызовет лишний warning, что чревато пропуском уже серьёзной ошибки, или меняет интерфейс стандартного оператора, что как раз есть классика наглядных пособий как делать не надо.

Добавлено через 10 минут и 20 секунд
Копирует, да вот беда: анализ подобных мелочей занимает лишнее время, а по закону Мёрфи, гласящему что всё, что может быть понято не правильно, именно так и будет понято, кто нибудь обязательно его вообще не заметит.


Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 18:34

А как на счёт объекта, декларация членов-данных которого занимают более пяти экранов? malloc от этого не зависит, а первое же присваивание мусор затрёт. А объект, знающий, что он - узел дерева с динамическим массивом потомков и при этом ещё одновременно содержащий несколько динамических массивов объектов других классов, чьи экземпляры не знают, где они валяются? в указатель отдельным присваиванием пишется NULL, потом присваивание всего объекта, затирающее остальной мусор. Только это не удобно. А удобно и уместно вызывать конструктор оператором new.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 18:48

ТарасАтавин, ты что к мелочам цепляешься? Тебе концепцию показывают. Естественно, что в нормальном коде должен быть и return *this. Он в данном случае не он главное. Главное, каким образом реализуется основная функциональность.

Что и куда копирует?

Добавлено через 9 минут и 45 секунд
Программиста надо уволить с записью в трудовой о непригодности к профессии.

А кто проинициализировал присваиваемый объект? Что будет, если будет вызван деструктор изначального объекта?

Объекты не думают. Они являются. И есть стандартное правило - освобождением ресурсов занимается тот, кто их выделяет. Исключение (условное) - умные указатели.

Вот и объясни, зачем мучаться с malloc/new()/деструктор/free, когда можно использовать new/delete? Более того, можно использовать умные указатели, и в этом случае тебе достаточно будет сделать только new, а все остальное ляжет на плечи указателя.

Именно с таким подходом его и не оказывается в коде релиза. И не только его, но и , наоборот, оказывается в коде.

Добавлено через 2 минуты и 36 секунд
Какая разница? Речь о том, что код читается, как , то есть обмен параметра местами с мусором, а не о том, что именно это он и означает.

не совсем, это слишком узко. правило в том, что у объекта должен быть хозяин (владелец), который управляет. выделение памяти может быть делегировано (фабрике например), делегировано может быть и освобождение (хотя это реже применяется).  владение может передаваться, что и происходит с умными указателями.
так что они не исключение, а подтверждение правила.

Добавлено через 1 минуту

это уже мозгоклюйство. ведь все всё поняли. 

  
Где ты мусор тут нашел? Оператор присваивания ВСЕГДА оперирует с инициализированными объектами. Если какой-то негодяй не инициализирует объекты в конструкторе, то это его проблемы. Дальнейшие рассуждения по поводу качества кода с ним можно не продолжать.

Существует миф, который заслуживает того, что бы его разоблачили.

Действительно: вставка у листа быстрая. Однако, реализация со стандартным аллокатором задействует оператор new. 
Который черезвычайно медленный. 

Настолько медленный, что за это время можно несколько раз вставить элемент размеров в 32 байта и в количествt 1000 штук (я делал замеры по скорости, но это было давно и точных цифр не помню) в вектор путем копирования его элементов в право (расширение), при условии, что у вектора достаточно резерва и он не реалокнется.

Таким образом, если вы используете стандартный аллокатор листа, который идет в с ним по дефолту, то по скорости работы на прикладных задачах он редко когда выигрывает у вектора. И никогда не выигрывает, если количество элементов - не велико.

Использовать его ради достижения перфоманса имеет смысл, если вы используете свои аллокаторы с уже заранее зарезервированной памятью. И не имеете потерь на её выделение оператором new