Здравствуйте, IT, Вы писали:

IT>Здравствуйте, TepMuHyc, Вы писали:

TMH>>Вот... Сотворил такой assignment.

IT>А зачем тогда вообще временная структура? Пиши прямо в сам класс

IT>

IT>my_class& operator=(const my_class& rhs)
IT>{
IT>   new(this) my_class(rhs); //создаем новый временный экземпляр класса в буфере tmp.
IT>   return *this;
IT>}
IT>

Если во время выполнения конструктора вылетает исключение то есть риск испортить данные предыдущего объекта и в результате получим исходный объект для которого вызывался оператор = в неопределенном состоянии( неясно какие данные в нем будут валидные, а какие нет ).

Здравствуйте, TepMuHyc, Вы писали:

TMH>Но... Гложут смутные сомнения: все так просто и прозрачно, но я нигде еще не видел такого подхода.

Правильно гложут...

TMH>Значит, ДОЛЖНЫ быть грабли. Вопрос ГДЕ?

В голове у тебя.

Здравствуйте, TepMuHyc, Вы писали:
TMH> memcpy(this, &tmp, sizeof(*this));//бинарно копируем временный экземпляр в TMH>Скажу сразу: класс безопасен для бинарного копирования — т.е. он не содержит ссылок и указателей на самого себя.
TMH>Значит, ДОЛЖНЫ быть грабли. Вопрос ГДЕ?

Недавно за пивом обсуждали эту тему...
Вся фишка в том, что приведение к типу "void*" это тяжкое наследие С, от которого надо избавляться. А в вызове memcpy() как раз это и происходит.

Если я правильно помню, никто не гарантирует, что размер ВСЕХ указателей между собой должен быть равен.
Посему, при такой операции приведения запросто можно потерять данные (на некоторой гипотетической машине, где динамическая память адресуется 64 битами, а статическая 16)
Уточните, если я не прав, но вроде, в стандарте это действительно не оговаривается...

2) alignment requirements my_class в массиве char, определенном "на стеке", могут не соблюдаться. Undefined behavior.

Как это? Почему это? Т.е., допустим есть
class MyClass{
public:
double d;
virtual ~MyClass()
{}
};

void fun(){
char ar[SOME_SIZE];
MyClass * pObj = new(ar+1)MyClass;
}

Имеется в виду что-то вроде такого? А это приведет к undefined behavior?