Здравствуйте, Desniza, Вы писали:
D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
shared_ptr хранит внутри себя deleter, так что уничтожаться объект будет вполне правильно.
Здравствуйте, 0xDEADBEEF, Вы писали:
V>>Ну если функции аллокации/деаллокации импортировать из отдельной "своей" DLL и не менять мемберы между собой, то почему бы и нет? DEA>Кстати, из серии "happy debugging": в определении класса просто поменяй местами обьявления data-мемберов и, если вся кодбаза не пересоберется (а это-частое явление), будет очень весело. DEA>Вопрос: из-за чего? За интересные ответы +3 в карму.
Так выравнивание.
short-short-int-int может занимать 12 байт, а вот short-int-short-int и все 16.
Здравствуйте, 0xDEADBEEF, Вы писали:
D>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально. D>>В этом собственно и вопрос — как оно работает на самом деле (такая связка) DEA>Это может работать (и работает) при соблюдении одного фундаментального условия: One Definition Rule (ODR) не нарушен.
Товарищи, вы чего? В shared_ptr используется "уничтожитель" в виде виртуального объекта, создаваемого в момент создания самого указателя (т.е. в исходной библиотеке).
Так что shared_ptr можно безопасно передавать между разными библиотеками и не париться.
Здравствуйте, XuMuK, Вы писали:
XMK>Здравствуйте, Desniza, Вы писали:
D>>Всем привет. D>>Возник такой вот вопрос над которым думаю уже некоторое время. D>>Как ведет себя к примеру шаред поинтер в связке exe<->dll D>>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер D>>и следовательно когда основному приложению он будет не нужен — объект удалится. D>>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
XMK>boost::shared_ptr можно использовать если передавать функцию из библиотеки, уничтожающую объект, через второй параметр шаблона.
Этого не достаточно. С памятью разные модули могут работать по разному, так что на счетчике слетит. Необходимо так-же и аллокатор передавать (третий параметр)
Здравствуйте, 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 без использования содержимого. По мне так, небольшое ограничение. Зато малость упрощает жизнь.
Всем привет.
Возник такой вот вопрос над которым думаю уже некоторое время.
Как ведет себя к примеру шаред поинтер в связке exe<->dll
к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер
и следовательно когда основному приложению он будет не нужен — объект удалится.
По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
В этом собственно и вопрос — как оно работает на самом деле (такая связка)
Здравствуйте, Desniza, Вы писали:
D>Всем привет. D>Возник такой вот вопрос над которым думаю уже некоторое время. D>Как ведет себя к примеру шаред поинтер в связке exe<->dll D>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер D>и следовательно когда основному приложению он будет не нужен — объект удалится. D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
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.
Здравствуйте, 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, Вы писали:
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.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>>>>Поведение не сменится. А реализация? C>>>А какая разница? Здесь реализация продиктована поведением. DEA>>То есть, нарушение ODR для smart_ptr допустимо? С чего бы это? C>В целом, да. По-моему, у него даже в исходниках есть комментарий типа: "Это нарушает ODR, но работает".
Глобальный поиск "ODR" по исходникам буст-1.44/smart_ptr дает фейл. Нет там упоминания ODR
Ищи отмазку поумнее.
__________
16.There is no cause so right that one cannot find a fool following it.
Re[3]: Shared_Ptr в библиотеке
От:
Аноним
Дата:
08.04.11 06:26
Оценка:
Здравствуйте, 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 для того, что в нем хранится.
Но он не работает с неполными классами.
Здравствуйте, Desniza, Вы писали:
D>Всем привет. D>Возник такой вот вопрос над которым думаю уже некоторое время. D>Как ведет себя к примеру шаред поинтер в связке exe<->dll D>к примеру если у нас в библиотеке объявлен смарт поинтер и класс, создается обхект и передается в приложение, либа больше не имеет указателей на этот смарт поинтер D>и следовательно когда основному приложению он будет не нужен — объект удалится. D>По сути получается алоцировали объект в DLL а грохаем в EXE, что не правильно изначально.
D>В этом собственно и вопрос — как оно работает на самом деле (такая связка)
В общем-то так, но если придерживаться некоторых правил при проектировании, то вполне можно использовать и умные указатели. При условии, конечно же, что одинаковые версии компиляторов и библиотек.