Russian Qt Forum

Как правильно создать shared_ptr если класс унаследован от нескольких родителей:


Пытаюсь создать shared_ptr:
Выводит кучу ошибок в недрах stl.
/usr/include/c++/4.7/ext/new_allocator.h:110: ошибка: 'xmlrpc_c::method' is an inaccessible base of 'CPingAdmin'

Наследуешься от xmlrpc_c::method, а тип пойнтера xmlrpc_c::methodPtr.

Если я делаю вот так:

То все нормально работает.
Но мне нужен в данном случае Qt-шный сигнал из класса, поэтому пришлось добавить QObject.

class CPingAdmin : public QObject, public xmlrpc_c::method

Спасибо, помогло.
Но появилась новая проблема - коннект сигнала к слоту:

Нужно кросс-привестись

C++ (Qt)
 
std::shared_ptr< xmlrpc_c::methodPtr > PingAdmFunc
            = std::make_shared< xmlrpc_c::methodPtr >( new CPingAdmin() );
 
CPingAdmin * pingAdmin = dynamic_cast <CPingAdmin *> (PingAdmFunc.get());
QObject::connect(pingAdmin , SIGNAL( PingReceived() ),  this, SLOT( on_admPing() ) );
 

[OFF]
Написано мало, но вот понять уже не так просто - заслуга "xmlrpc_c::methodPtr". И "крутые" скобки с пробелами  этого не компенсируют  :)
[/OFF]

std::make_shared вызывает placement new, и затем конструктор и переданными ему аргументами.
Зачем вы два раза создаёте объект xmlrpc_c::method?
Правильно так:
Или
В зависимости от того, какого типа указатель вам нужен в итоге.
std::make_shared и служит для того, чтобы самому не вызывать оператор new, а заодно и расположить объект и его счётчик ссылок в одном куске памяти + ещё какие-то там оптимизации.
Заодно советую почитать про enable_shared_from_this.

Так не работает, если внимательно посмотреть сто создается в шареде xmlrpc_c::methodPtr а не xmlrpc_c::method

Окей, тогда из текста ошибки ('xmlrpc_c::method' is an inaccessible base of 'CPingAdmin'), понятно, что вы наследуетесь приватно от xmlrpc_c::method. Отсюда и проблема.

то есть нужно так

Поясните такие моменты

1) Зачем здесь make_shared? Почему не просто
Вообще какие преимущества дает make_shared? (по сравнению с просто созданием шареного указателя)

2)  А как же у ТС откомпилилось - ведь конструктора xmlrpc_c::method принимающего указатель наверняка нет. Что же произошло?

Спасибо

Ну легко же нагугливается (http://stackoverflow.com/a/20895705/2080453).

Видимо, я наивно предположил, что xmlrpc_c::methodPtr -- это typedef method * methodPtr внутри класса xmlrpc_c::method.
Как оказалось, это отдельный класс, как раз принимающий в конструктор указатель на xmlrpc_c::method, что автор и продемонстрировал. Приватное наследование от этого класса как раз и привело к такой ошибке.

Не за что ;-)

Мдааа... Аргументация впечатляет
Как говорится "вспомнила баба как девкой была". Как c QString - так никто число malloc не считает (хоть их там тьма), а тут во как - аж 2(!) вместо одного, ай-яй-яй. Дальше еще интереснее
В общем я так понял что weak_ptr не обещает корректности если шареный указатель создан через make_shared. Не слабо!

В общем еще раз убедился что изучать std надо в меру. 

поведение weak_ptr вполне себе корректно.


под капотом есть два счетчика: количество сильных ссылок и слабых.
кроме этого - указатель на сам объект-ресурс смарт-поинтера.

1.
случай с двумя аллокациями:

имеем два указателя: на счетчики, и на объект-ресурс.

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

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

таким образом, последний шаред_птр грохнет объект-ресурс, и освободит его память.
последний смарт-поинтер (шаред или вик) грохнет объект-счетчиков, и освободит  его память.

в случае, если в памяти где то будет оставаться живой шаред_птр,
то в памяти будет висеть и объект-ресурс, и объект-счетчиков.

в случае, если в памяти где то будет оставаться живой вик_птр,
то в памяти будет висеть объект-счетчиков.

недостатки:
две аллокации - две дорогостоящие операции выделея,
и две ещё более дорогостоящих операций по освобождению.

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


2.
случай с одной аллокацией:

make_shared разом выделяет большой кусок,
в котором располагает и объект-счетчиков, и объект-ресурс.

например, так:


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

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

аналогично первому случаю, последний шаред_птр грохнет объект-ресурс (позовет деструктор)

но пока счетчик слабых ссылок ещё не обнулился, нельзя удалять саму память.
иначе, вик_птр станут неконсистентными.

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


резюмируя:

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

на мой взгляд, 2й способ работы со смарт-поинтерами предпочтительнее, нежели первый.
зная немножко, как оно там устроенно внутри, я понимаю, что 2й способ работает эффективнее.

но если пренебречь этой эффективностью,
то с точки зрения использования особой разницы нет.

Я бы еще добавил про исключения... но не буду. :)

Потому что, главная фраза темы уже сказана:

Все уточняющие вопросы в теме, задавались исключительно, что-бы сказать это. :)

Тему можно закрывать.  ;D

Понял, в случае make_shared зовется деструктор - а не delete

Ну дорого/дешево познается в сравнении. Напр сколько здесь будет таких операций?

C++ (Qt)
QStringList lst = QString("This is text").split(" ");

:) А что-то типа QRegExp еще похлеще. Но ни разу не видел чтобы это хоть кого-то остановило, Напротив, задействовать QRegExp считается делом чести. Как-то слышал типа
Наверное уже и обогнали  :)

Ну мне пригодился make_shared, и даже не он а allocate_shared, когда я уперся в фрагментацию памяти. Выделялось несколько миллионов объектов по 100 байт. Пришлось городить пул и выделять через allocate_shared.