Глюк QList или моя ошибка

[brankovic]

Есть структура...

А на винде дело-то? А то на линуксах тупо valgrind запустил, часто сразу понятно, что не так..

[ритт]

ну вообще-то будет, по умолчанию происходит что-то типа memcpy насколько я знаю, а конструкторы кустрингов вроде не вызовуться

мета-тип не примитив и не мувэйбл - memcpy происходить не будет.

[lit-uriy]

2) в данном случае будет вызываться не конструктор копирования, а оператор присваивания.

тут нужно быть по осторожнее т.к. теория может расходится с практикой (оптимизация компилятора)
Тыц

[Igors]

2) в данном случае будет вызываться не конструктор копирования, а оператор присваивания.

тут нужно быть по осторожнее т.к. теория может расходится с практикой (оптимизация компилятора)
Тыц

Как пояснил Rcus - это стандартная оптимизация практически для всех современных компиляторов.

Код

C++ (Qt)
MyObject CreateObj( void )   // наглое возвращение объекта по значению
{
 MyObject obj;
 return obj;
}
...
MyObject theObj = CreateObj();
 

Здесь компилятор не позовет деструктор для локального obj, итого будет вызван всего 1 конструктор MyObj. Однако никакая оптимизация не заменяет конструирование на присваивание или наоборот, напр

Код

C++ (Qt)
theObj = CreateObj();  // theObj был объявлен выше
 

А вот здесь как ни оптимизируй, а будет вызван оператор присваивания и деструктор
Кстати интересно проверить (для первого случая) - а что будет если конструктор копирования и по умолчанию чем-то различаются?

Edit; наверное правильнее сказать: в первом случае локальный obj вообще не создается, а сразу используется "место назначения" (theObj)

[brankovic]

Edit; наверное правильнее сказать: в первом случае локальный obj вообще не создается, а сразу используется "место назначения" (theObj)

Именно. Только это не "какая-то оптимизиция некоторых компиляторов", это разрешено и поощряется стандартом, называется copy constructor elision. Даже если конструктор копирования и конструктор по умолчанию различаются, компилятор имеет право бездумно сократить, опять в соответствии со стандартом. Гарантий нет. Вплоть до того, что на разном уровне оптимизации будет работать по-разному.

[Igors]

Именно. Только это не "какая-то оптимизиция некоторых компиляторов",

Я такого не говорил, наоборот 

Даже если конструктор копирования и конструктор по умолчанию различаются, компилятор имеет право бездумно сократить, опять в соответствии со стандартом. Гарантий нет. Вплоть до того, что на разном уровне оптимизации будет работать по-разному.

Хммм... интересно разобраться. Представим ситуацию когда:

- конструктор по умолчанию заводит новый shared объект (указатель на него - член класса)
- конструктор копирования только увеличивает число ссылок на него (как и оператор присваивания)

И что - это будет работать по-разному?
Хотя я бы лично по значению объектов бы не возвращал (ну разве что-то типа QPoint, QRect)