shared_ptr and incomplete types
The documentation at http://www.boost.org/libs/smart_ptr/shared_ptr.htm states that "T may be void, but in that case, either an explicit delete function must be passed in, or the pointed-to object must have a trivial destructor." I notice that the implementation available at boost.org does not allow the single-argument ctor to be called on an incomplete type, e.g.: class simple; simple * createSimple(); shared_ptr<simple> simpleFactory() { return shared_ptr<simple>(createSimple()); } The documentation on the single-argument ctor, though, does not state that T must be a complete type. Is the implementation stricter than the documentation, or is the documentation incomplete? I'm writing an article on the smart pointers for the CUJ, and I'd like to know if I can correctly state "The default behavior for shared_ptr is to require complete types. You can, however, manage an incomplete type if you provide a function or function object, which will be called when the owned object is destroyed." -- Jim
From: "Jim Hyslop"
The documentation at http://www.boost.org/libs/smart_ptr/shared_ptr.htm states that "T may be void, but in that case, either an explicit delete function must be passed in, or the pointed-to object must have a trivial destructor."
Well, it no longer does; see the version in the CVS that is more up to date (but still needs work.)
I notice that the implementation available at boost.org does not allow the single-argument ctor to be called on an incomplete type, e.g.:
class simple; simple * createSimple();
shared_ptr<simple> simpleFactory() { return shared_ptr<simple>(createSimple()); }
Correct. This is not legal. The argument to the single-arg constructor, let's call it p, must be a pointer to a complete type, and 'delete p' must be well-formed and with defined behavior.
The documentation on the single-argument ctor, though, does not state that T must be a complete type. Is the implementation stricter than the documentation, or is the documentation incomplete?
Again, see the documentation in the CVS.
I'm writing an article on the smart pointers for the CUJ, and I'd like to know if I can correctly state "The default behavior for shared_ptr is to require complete types. You can, however, manage an incomplete type if you provide a function or function object, which will be called when the owned object is destroyed."
Not really... The "default behavior" of shared_ptr<> is to _not_ require complete types unless necessary. The only methods that need a complete type are the single-argument constructor and the single-argument reset. The latest CVS changes (the documentation hasn't been updated yet) relax these requirements even further. Now the template parameter T is never required to be a complete type (i.e. can be void.) The only requirement is that the passed pointer must (a) point to a complete type, and (b) be implicitly convertible to T*. (In practice this implies that T must be complete or void at this point.) Hopefully this makes sense. ;-)
From: "Jim Hyslop"
The documentation at http://www.boost.org/libs/smart_ptr/shared_ptr.htm states that "T may be void, but in that case, either an explicit delete function must be passed in, or the pointed-to object must have a
--- In Boost-Users@y..., "Peter Dimov"
destructor."
Well, it no longer does; see the version in the CVS that is more up to date (but still needs work.) Ah, of course.
Again, see the documentation in the CVS.
I'm writing an article on the smart pointers for the CUJ, and I'd like to know if I can correctly state "The default behavior for shared_ptr is [...] Not really... The "default behavior" of shared_ptr<> is to _not_ require complete types unless necessary. Yes, poor wording on my part - I don't know why I used the phrase "default behavior" applied to a single-argument ctor. Good thing the
Do I detect a theme here? :-) article is still in the draft stage!
Hopefully this makes sense. ;-) Yes, thanks. I've just refreshed my CVS checkout. I noticed at least one other new item, shared_polymorphic_downcast, has been added, so I'll have to re-read the documentation and the files to make sure I'm up to date.
Thanks for the tips! -- Jim
participants (3)
-
Jim Hyslop
-
jimhyslopca
-
Peter Dimov