Здравствуйте, 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