Всем привет.
Возник такой вот вопрос над которым думаю уже некоторое время.
Как ведет себя к примеру шаред поинтер в связке exe<->dll
к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер
и следовательно когда основному приложению он будет не нужен — объект удалится.
По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.

В этом собственно и вопрос — как оно работает на самом деле (такая связка)

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

D>Всем привет.
D>Возник такой вот вопрос над которым думаю уже некоторое время.
D>Как ведет себя к примеру шаред поинтер в связке exe<->dll
D>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер
D>и следовательно когда основному приложению он будет не нужен — объект удалится.
D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.

D>В этом собственно и вопрос — как оно работает на самом деле (такая связка)

boost::shared_ptr можно использовать если передавать функцию из библиотеки, уничтожающую объект, через второй параметр шаблона.

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

D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
shared_ptr хранит внутри себя deleter, так что уничтожаться объект будет вполне правильно.

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

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

D>>Всем привет.
D>>Возник такой вот вопрос над которым думаю уже некоторое время.
D>>Как ведет себя к примеру шаред поинтер в связке exe<->dll
D>>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер
D>>и следовательно когда основному приложению он будет не нужен — объект удалится.
D>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.

D>>В этом собственно и вопрос — как оно работает на самом деле (такая связка)

XMK>boost::shared_ptr можно использовать если передавать функцию из библиотеки, уничтожающую объект, через второй параметр шаблона.
Этого не достаточно. С памятью разные модули могут работать по разному, так что на счетчике слетит. Необходимо так-же и аллокатор передавать (третий параметр)

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

D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
Это может работать (и работает) при соблюдении одного фундаментального условия: One Definition Rule (ODR) не нарушен.
То есть: и в ехе и в длл:
— использует общий operator new и delete
— одинаковае реализации конструкторов копирования и деструкторов классов используемых там и там.
— все остальное, что может повлиять на копируемость и удалаемость обьектов используемых и там и там тоже одинаково.

Добиться этого очень просто: и ехе и длл должны собираться с одними и теми же заголовочными файлами.
В противном случае возможно всякое. И это называется "Dll Hell"

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

D>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
DEA>Это может работать (и работает) при соблюдении одного фундаментального условия: One Definition Rule (ODR) не нарушен.
Товарищи, вы чего? В shared_ptr используется "уничтожитель" в виде виртуального объекта, создаваемого в момент создания самого указателя (т.е. в исходной библиотеке).

Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.

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

C>Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
А как по поводу версий этого shared_ptr?
Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
...Причем, Y еще не вышла...

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

C>>Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
DEA>А как по поводу версий этого shared_ptr?
DEA>Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
Не сменится. Это поведение в shared_ptr — by design (возможность использования incomplete-классов).

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

C>Здравствуйте, 0xDEADBEEF, Вы писали:

C>>>Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
DEA>>А как по поводу версий этого shared_ptr?
DEA>>Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
C>Не сменится. Это поведение в shared_ptr — by design (возможность использования incomplete-классов).
Поведение не сменится. А реализация?

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

DEA>>>Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
C>>Не сменится. Это поведение в shared_ptr — by design (возможность использования incomplete-классов).
DEA>Поведение не сменится. А реализация?
А какая разница? Здесь реализация продиктована поведением.

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

C>Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>>>>Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
C>>>Не сменится. Это поведение в shared_ptr — by design (возможность использования incomplete-классов).
DEA>>Поведение не сменится. А реализация?
C>А какая разница? Здесь реализация продиктована поведением.
То есть, нарушение ODR для smart_ptr допустимо? С чего бы это?

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

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

C>>Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>>>>>Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
C>>>>Не сменится. Это поведение в shared_ptr — by design (возможность использования incomplete-классов).
DEA>>>Поведение не сменится. А реализация?
C>>А какая разница? Здесь реализация продиктована поведением.
DEA>То есть, нарушение ODR для smart_ptr допустимо? С чего бы это?

Мне кажется по умолчанию может браться текущий делитер и запоминаться во внутренних структурах.
Т.е. фактически один объект но в зависимости от места создания возможно разные будут внутренние данные (делитер в частности)

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

D>Мне кажется по умолчанию может браться текущий делитер и запоминаться во внутренних структурах.
D>Т.е. фактически один объект но в зависимости от места создания возможно разные будут внутренние данные (делитер в частности)
Ога-ога.
А теперь, предположим, в ехе у тебя совсем старый shared_ptr — скажем, из буста-1.0 или еще младше (забыл, когда он в бусте появился)
А в длле, которую ты скомпилил только что, shared_ptr из самого наисвежайшего буста.
Вопрос: будет ли это работать вместе?

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

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

D>>Мне кажется по умолчанию может браться текущий делитер и запоминаться во внутренних структурах.
D>>Т.е. фактически один объект но в зависимости от места создания возможно разные будут внутренние данные (делитер в частности)
DEA>Ога-ога.
DEA>А теперь, предположим, в ехе у тебя совсем старый shared_ptr — скажем, из буста-1.0 или еще младше (забыл, когда он в бусте появился)
DEA>А в длле, которую ты скомпилил только что, shared_ptr из самого наисвежайшего буста.
DEA>Вопрос: будет ли это работать вместе?
посмотрел 1.22.0
там просто другая имплементация... ничего общего

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

D>>Мне кажется по умолчанию может браться текущий делитер и запоминаться во внутренних структурах.
D>>Т.е. фактически один объект но в зависимости от места создания возможно разные будут внутренние данные (делитер в частности)
DEA>Ога-ога.
DEA>А теперь, предположим, в ехе у тебя совсем старый shared_ptr — скажем, из буста-1.0 или еще младше (забыл, когда он в бусте появился)
DEA>А в длле, которую ты скомпилил только что, shared_ptr из самого наисвежайшего буста.
DEA>Вопрос: будет ли это работать вместе?
Ну если функции аллокации/деаллокации импортировать из отдельной "своей" DLL и не менять мемберы между собой, то почему бы и нет?

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

V>Ну если функции аллокации/деаллокации импортировать из отдельной "своей" DLL и не менять мемберы между собой, то почему бы и нет?
Кстати, из серии "happy debugging": в определении класса просто поменяй местами обьявления data-мемберов и, если вся кодбаза не пересоберется (а это-частое явление), будет очень весело.
Вопрос: из-за чего? За интересные ответы +3 в карму.

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

DEA>>>Поведение не сменится. А реализация?
C>>А какая разница? Здесь реализация продиктована поведением.
DEA>То есть, нарушение ODR для smart_ptr допустимо? С чего бы это?
В целом, да. По-моему, у него даже в исходниках есть комментарий типа: "Это нарушает ODR, но работает".

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

V>>Ну если функции аллокации/деаллокации импортировать из отдельной "своей" DLL и не менять мемберы между собой, то почему бы и нет?
DEA>Кстати, из серии "happy debugging": в определении класса просто поменяй местами обьявления data-мемберов и, если вся кодбаза не пересоберется (а это-частое явление), будет очень весело.
DEA>Вопрос: из-за чего? За интересные ответы +3 в карму.
Так выравнивание.

short-short-int-int может занимать 12 байт, а вот short-int-short-int и все 16.

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

EA>А теперь, предположим, в ехе у тебя совсем старый shared_ptr — скажем, из буста-1.0 или еще младше (забыл, когда он в бусте появился)
DEA>А в длле, которую ты скомпилил только что, shared_ptr из самого наисвежайшего буста.
DEA>Вопрос: будет ли это работать вместе?
С большой вероятностью не будет. Увы, издержки отсутствия C++ ABI.

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

C>short-short-int-int может занимать 12 байт, а вот short-int-short-int и все 16.
Ответ умный, но не интересный. Есть интереснее. -1

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

C>Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>>>>Поведение не сменится. А реализация?
C>>>А какая разница? Здесь реализация продиктована поведением.
DEA>>То есть, нарушение ODR для smart_ptr допустимо? С чего бы это?
C>В целом, да. По-моему, у него даже в исходниках есть комментарий типа: "Это нарушает ODR, но работает".
Глобальный поиск "ODR" по исходникам буст-1.44/smart_ptr дает фейл. Нет там упоминания ODR
Ищи отмазку поумнее.

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

C>Здравствуйте, 0xDEADBEEF, Вы писали:

D>>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>>>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
DEA>>Это может работать (и работает) при соблюдении одного фундаментального условия: One Definition Rule (ODR) не нарушен.
C>Товарищи, вы чего? В shared_ptr используется "уничтожитель" в виде виртуального объекта, создаваемого в момент создания самого указателя (т.е. в исходной библиотеке).

C>Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.

Тем не менее, соблюдение ODR требуется. Например, sp_counted_base может зависеть от ключей компилятора и макроопределений. Разборка с GCC 4.3.2, когда в одном so оказалось, что некоторые объектники собраны с дополнительным ключиком заняла примерно 3 дня, выглядело так, что объект в std::tr1::shared_ptr удалялся приявно не нулевом счетчике ссылок. Но один их shared_ptr считал иначе по причине конструкции sp_counted_base.

intrusive_ptr более безопасен. Он фактически зависит только от соблюдения ODR для того, что в нем хранится.

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

C>>В целом, да. По-моему, у него даже в исходниках есть комментарий типа: "Это нарушает ODR, но работает".
DEA>Глобальный поиск "ODR" по исходникам буст-1.44/smart_ptr дает фейл. Нет там упоминания ODR
DEA>Ищи отмазку поумнее.
Я это видел в районе Boost 1.22, т.е. очень давно (когда я ещё в Boost контрибьютил...).

Здравствуйте, Аноним, Вы писали:

А>Тем не менее, соблюдение ODR требуется. Например, sp_counted_base может зависеть от ключей компилятора и макроопределений. Разборка с GCC 4.3.2, когда в одном so оказалось, что некоторые объектники собраны с дополнительным ключиком заняла примерно 3 дня, выглядело так, что объект в std::tr1::shared_ptr удалялся приявно не нулевом счетчике ссылок. Но один их shared_ptr считал иначе по причине конструкции sp_counted_base.
Это уже вопросы ABI, тут даже ODR не поможет, если заголовки скомпилированы с одними настройками, а реализация с другими.

А>intrusive_ptr более безопасен. Он фактически зависит только от соблюдения ODR для того, что в нем хранится.
Но он не работает с неполными классами.

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

C>Здравствуйте, Аноним, Вы писали:

А>>Тем не менее, соблюдение ODR требуется. Например, sp_counted_base может зависеть от ключей компилятора и макроопределений. Разборка с GCC 4.3.2, когда в одном so оказалось, что некоторые объектники собраны с дополнительным ключиком заняла примерно 3 дня, выглядело так, что объект в std::tr1::shared_ptr удалялся приявно не нулевом счетчике ссылок. Но один их shared_ptr считал иначе по причине конструкции sp_counted_base.
C>Это уже вопросы ABI, тут даже ODR не поможет, если заголовки скомпилированы с одними настройками, а реализация с другими.

Там было веселее — было 2 реализации, несовместимые друг с другом и как назло в использовались обе Так уж было все написано, включая процедуру сборки

Согласись, неприятно, когда -march=pentiumpro неожиданно все ломает?

А>>intrusive_ptr более безопасен. Он фактически зависит только от соблюдения ODR для того, что в нем хранится.
C>Но он не работает с неполными классами.

Единственное ограничение — невозможноть передачи такого instrusive_ptr без использования содержимого. По мне так, небольшое ограничение. Зато малость упрощает жизнь.

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

D>Всем привет.
D>Возник такой вот вопрос над которым думаю уже некоторое время.
D>Как ведет себя к примеру шаред поинтер в связке exe<->dll
D>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер
D>и следовательно когда основному приложению он будет не нужен — объект удалится.
D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.

D>В этом собственно и вопрос — как оно работает на самом деле (такая связка)

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

Можно тут подробнее : http://chadaustin.me/cppinterface.html