delaying destructor compile on imcomplete type
IIRC, one of boost's smart ptrs can be used with an incomplete type. How is the compile of the destructor delayed? ie ~my_smart_ptr() { get()->~T(); // error: T is an incomplete type } I wondered through lots of the shared_ptr code, but I got a bit bleary-eyed. On that note, does anyone have a script or preprocessor call or something that converts all the boost code into the 'clean and ideal boost'? ie the one without the layers and layers of compiler workarounds, etc? I think that version would be a much easier read. And maybe some day all compilers will support that version too. We can but dream... Tony
On 6/7/06, Gottlob Frege
IIRC, one of boost's smart ptrs can be used with an incomplete type. How is the compile of the destructor delayed?
As I understand it, it's a consequence of allowing custom deleters. The destructor knows that it will call a boost::function-type thing on the pointer, but only needs the signature of that. The actual deleter is set on construction of the shared_ptr, at which point the type is complete. ~ Scott McMurray
Gottlob Frege wrote:
IIRC, one of boost's smart ptrs can be used with an incomplete type. How is the compile of the destructor delayed?
ie
~my_smart_ptr() { get()->~T(); // error: T is an incomplete type }
In pseudocode, something along the lines of: class my_smart_ptr { T * p; void (*f)( T* ); my_smart_ptr( T* p ): p( p ), f( &delete ) {} ~my_smart_ptr() { f(p); } };
I wondered through lots of the shared_ptr code, but I got a bit bleary-eyed. On that note, does anyone have a script or preprocessor call or something that converts all the boost code into the 'clean and ideal boost'? ie the one without the layers and layers of compiler workarounds, etc?
shared_ptr doesn't have _that_ many compiler workarounds. :-)
participants (3)
-
Gottlob Frege -
me22 -
Peter Dimov