[shared_ptr] get_deleter is for what?
I realise my requirements may be rather specific, but it seems shared_ptr has picked up some typeid baggage, which I can't afford. I'm compiling using MSVC7.1 and for each object for which I use a shared_ptr, I gain an entry in my binary. For example, class Monty generates the following string in my exe: ?AU?$checked_deleter@VMonty@@@boost@@ This seems to be sucked in by this function in class sp_counted_base_impl: virtual void * get_deleter(std::type_info const & ti) { return ti == typeid(D)? &del: 0; } It isn't being used, and I can't actually see anything in boost using this, so maybe the compiler isn't doing a great job at stripping unused stuff? Anyone shed some light on this for me? Thanks Mark
Mark Holloway wrote:
I realise my requirements may be rather specific, but it seems shared_ptr has picked up some typeid baggage, which I can't afford.
I'm compiling using MSVC7.1 and for each object for which I use a shared_ptr, I gain an entry in my binary. For example, class Monty generates the following string in my exe: ?AU?$checked_deleter@VMonty@@@boost@@
This seems to be sucked in by this function in class sp_counted_base_impl: virtual void * get_deleter(std::type_info const & ti) { return ti == typeid(D)? &del: 0; }
It isn't being used, and I can't actually see anything in boost using this, so maybe the compiler isn't doing a great job at stripping unused stuff?
This string is the mangled representation of typeid(D).name(), where D in your case is boost::checked_deleter<Monty>. On MSVC, type_info::operator== is implemented as a string comparison so it can work across DLLs. The compiler can't strip the string away because it is referenced in a virtual member function and without whole program optimization it is not possible to prove that this member function is never called. This problem should be fixed in the latest CVS version of boost::shared_ptr. If you can try it and report back, it would be much appreciated.
Mark Holloway wrote:
I realise my requirements may be rather specific, but it seems shared_ptr has picked up some typeid baggage, which I can't afford.
Whyever not?
I'm compiling using MSVC7.1 and for each object for which I use a shared_ptr, I gain an entry in my binary. For example, class Monty generates the following string in my exe: ?AU?$checked_deleter@VMonty@@@boost@@
This seems to be sucked in by this function in class sp_counted_base_impl: virtual void * get_deleter(std::type_info const & ti) { return ti == typeid(D)? &del: 0; }
It isn't being used, and I can't actually see anything in boost using this, so maybe the compiler isn't doing a great job at stripping unused stuff?
Anyone shed some light on this for me?
Virtual functions generally can't be dropped by the linker because it cannot tell whether or not they are used. Ben.
participants (3)
-
Ben Hutchings
-
Mark Holloway
-
Peter Dimov