semen.s.semen, у тебя для каждого экземпляра test деструктор вызывается единожды - для экземпляра в map и для экземпляра на стеке (test t).

semen.s.semen, а как же?! Если ты явно не указал на отсутствие реализации конструктора копирования, он будет создан по умолчанию с реализацией простого копирования байт-в-байт. И вообще - создавать на стеке экземпляры класса, а потом помещать их в map, созданный в куче - моветон.

Делай так:

Я маленько наврал. :) Метод emplace принимает ссылки на rvalue:

Поэтому, надо делать что-то типа:

В этом случае, на стеке будет создан временный экземпляр класса test, а при передаче в map будет задействован либо конструктор копии, либо конструктор пересылки, в зависимости от того, реализованы ли эти конструкторы для класса. Это то, о чем писалось в другой ветке - RVO/NRVO.

MasterZiv, ненаследованные (собственные) члены конструктор копирования по умолчанию может и обычным копированием сделать через MOVSB, задав в регистрах #SI и #DI источник и приемник соответственно, а в регистре #CX - кол-во байт. Конечно, зависит от конкретной реализации компилятора.

Кстати, обращал внимание, как сейчас компиляторы помещают в стек параметры? Никаких тебе множественных PUSH! :) Сразу грузит в #SP значение с учётом смещения для всех параметров, формируя кадр стека и помещает туда параметры обычным MOV.

MasterZivТы хотел написать НЕ ДЕЛАЙ так ?Я чуть ниже исправился. :)

MasterZivУ тебя в коде вызывается MOVE-конструктор, который ты не замечаешь, игнорируешь, а потом думаешь (неверно), что деструктор вызывается лишний раз.Конструктор пересылки, в отличие от конструктора копии, не создается по умолчанию - необходима явная реализация.

Dima Trdb_dev, в этой книжке Эффективный и современный С++. 42 рекомендации по использованию C++11 и C++14 написано как устроен std::move. Он "работает" во время компиляции.Как еще должен "работать" обычный шаблон, как не во время компиляции? И причем тут, вообще, шаблон std::move?

CEMbВо-первых, в объект входит указатель на виртуальную таблицу методов, если есть (это MS)
Плюс ещё оптимизатор, вроде, может чего-нить местами переставить.Собственно, указатель this, это указатель на указатель на таблицу виртуальных методов - это еще в Borland TASM было.
CEMbВо-вторых, если есть родительские методы, то &x и реальное начало данных могут отличаться.Не может! У экземпляра класса есть лишь одна таблица виртуальных методов, которая хранится отдельно от экземпляра класса и все экземпляры одного и того же класса имеют один и тот же указатель на таблицу виртуальных методов. При наследовании, компилятор создает копию родительской таблицы виртуальных методов и добавляет в конец этой копии указатели на виртуальные методы наследника в порядке их объявления. Конец таблицы виртуальных методов определяется указателем NULL.

CEMbrdb_dev, ну, может на счёт второго я и напутал что-то, я не смог вспомнить пример. Но первого достаточно, чтобы не копировать память вручную. Это потенциальная ошибка, у тебя могут быть пара указателей на класс А, один из которых на самом деле указывает на дочерний класс В. В случае прямого копирования получится неправильный экземпляр.
Хотя, интересный хак получается :)Почему должен получится неправильный экземпляр? Давай рассмотрим простой пример:

В соответствии с ABI, экземпляр B в памяти будет выглядеть следующим образом (на x86_32 при выравнивании на QWORD):


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

Dima T, конечно, экземпляры чужих классов нехорошо просто копировать, особенно, если не знаешь как они устроены, это ежу понятно! Но создать реализацию конструктора пересылки своего класса, которая будет копировать данные байт-в-байт, а затем подчищать источник - вполне допустимо.

CEMbпотому что vtable pointer от одного класса перезапишется поверх vtp другого класса. Если использовать this-ы.Естественно, копировать указатель на таблицу виртуальных методов не стОит! Он и так нормально проинициализируется.
CEMbа, ты какой хитрый! ты берёшь адрес с переменной.Конечно! Что же еще? 😊
CEMbа это ещё хуже, потому что напишешь копировальщик. А потом забудешь, будешь рефакторить и перед a1 поставишь какую-нить другую переменную - и получится трудноуловимая ошибка.Поэтому, я и написал, что предпочитаю засовывать всё мемберы в инкапсулируемую структуру. Её проще копировать и даже можно написать inline конструктор копии или конструктор пересылки такой структуры.
CEMbНет, я согласен, так делать можно при должной осторожности . Но я бы лично так не делал. Выгода не понятна, сомневаюсь в наличии таких классов, у которых movsb даст много выигрыша по сравнению с по-переменным копированием. Если в классе есть большие блоки данных (массивы, векторы), у них свой копировальщик. Все остальные копируются вручную.Представь, что у тебя не три и не четыре члена, размером не более размерности регистра платформы, которые компилятор может распихать в регистры EAX, EDX, ECX, EBX, а гораздо больше и, к примеру, все long long, а приложение 32-х разрядное. Я пихаю все члены в структуру, чтобы не пропустить в конструкторе копии или пересылки какой-нибудь член, а гарантировано всё скопировать. Для конструктора пересылки это вполне нормальный подход, так как после копирования можно просто заполнить структуру источника нолями, что позволит обнулить и указатели, чтобы деструктор не освободил данные, которыми уже владеет объект-приемник.
CEMbКстати, а что будет, если shared_ptr так скопировать? Т.е. понятно, что счётчик не увеличится, но что будет когда объект класса содержащего копию этого shared_ptr будет уничтожен?Не надо просто копировать shared_ptr - он на это не расчитан. Другое дело, если ты создаешь свой собственный класс safe-thread смарт-указателя и чтобы при возврате его как rvalue через стек не дёргать каждый раз переменную подсчёта ссылок в синглетоне через медленные атомарные операции работы с памятью, ты можешь написать конструктор пересылки, который будет лишь копировать данные из источника и обнулять источник. Но это при условии, что синглетон типа не содержит реализацию реферальных ссылок на смарт-указатели.