On 08-10-2013 00:43, Gavin Lambert wrote:
On 10/7/2013 10:48 PM, Quoth Thorsten Ottosen:
If the idea is to be 100% shared_ptr interface compatible, it may be easier just to extend boost::shared_ptr a little:
typedef boost::shared_ptr<boost::non_nullable<T>> SharedT;
I don't like that.
If you're suggesting using a wrapper type without changing shared_ptr, that won't work because the shared_ptr itself could still be empty, so you haven't gained anything.
I'm not.
If you're suggesting specialising shared_ptr for that subtype, I don't see any benefit in doing this over defining a new pointer type, since you have to redefine everything in a specialisation anyway.
I'm not.
And there's undoubtedly some existing templated code that operates on boost::shared_ptr<T> that would be confused by this,
Well, wouldn't that code use shared_ptr<T>::element_type?
or at the very least not operate efficiently by including tests for null.
I'm confused. What tests? Anyway, in Boost.PtrContainer you can change the "null behavior" by saying ptr_vector<T> vec_non_nulls; ptr_vector<nullable<T>> vec_with_nulls; The shared_ptr implementation would have to check its template argument and emit special code in a few places. This is very easy to do, and far easier than specializing/wrapping the class.
typedef boost::shared_ptr<boost::non_nullable<T>> WeakT;
I assume that was a typo. (Weak pointers are not especially useful without being able to represent null anyway.)
Yes, sorry, a typo. I suppose there is still a need to break cycles. Why would this have changed. -Thorsten