Всем привет.
Возник такой вот вопрос над которым думаю уже некоторое время.
Как ведет себя к примеру шаред поинтер в связке 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"
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
D>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально. D>>В этом собственно и вопрос — как оно работает на самом деле (такая связка) DEA>Это может работать (и работает) при соблюдении одного фундаментального условия: One Definition Rule (ODR) не нарушен.
Товарищи, вы чего? В shared_ptr используется "уничтожитель" в виде виртуального объекта, создаваемого в момент создания самого указателя (т.е. в исходной библиотеке).
Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
Здравствуйте, Cyberax, Вы писали:
C>Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
А как по поводу версий этого shared_ptr?
Вот ты зуб дашь за то, что он не сменился между версиями буста X и Y?
...Причем, Y еще не вышла...
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 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-классов).
Поведение не сменится. А реализация?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 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 допустимо? С чего бы это?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 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 из самого наисвежайшего буста.
Вопрос: будет ли это работать вместе?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 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 и не менять мемберы между собой, то почему бы и нет?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Ну если функции аллокации/деаллокации импортировать из отдельной "своей" DLL и не менять мемберы между собой, то почему бы и нет?
Кстати, из серии "happy debugging": в определении класса просто поменяй местами обьявления data-мемберов и, если вся кодбаза не пересоберется (а это-частое явление), будет очень весело.
Вопрос: из-за чего? За интересные ответы +3 в карму.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 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
__________
16.There is no cause so right that one cannot find a fool following it.