[ptr_container] How to transfer ownership from smart_ptr to ptr_container
Hi!
Is there any smart_ptr and ptr_container that can transfer ownership of
pointer, to avoid useless copy-construction and destruction of the object.
More less scenario can be like that.
1. smart pointer handles pointer to the huge data.
2. pointer is transfered via signal to the object that has queue of them.
2a. remark not all object are going to the queue, so there is a need to keep
them in smart pointer.
3. Queue sends away pointer, or internally destroys (respectively to demand of
another signal in the program.
More less the simplified draft is shown below.
Maybe I have to use vector
Seweryn Habdank-Wojewódzki skrev:
Hi!
Is there any smart_ptr and ptr_container that can transfer ownership of pointer, to avoid useless copy-construction and destruction of the object.
I guess you can't release a shared_ptr, even though it's use count is 1. Peter, any reason for not having a release() given that its precondition is unique() is true?
Maybe I have to use vector
instead of ptr_container?
Seems like it. -Thorsten
Thorsten Ottosen wrote:
Seweryn Habdank-Wojewódzki skrev:
Hi!
Is there any smart_ptr and ptr_container that can transfer ownership of pointer, to avoid useless copy-construction and destruction of the object.
I guess you can't release a shared_ptr, even though it's use count is 1. Peter, any reason for not having a release() given that its precondition is unique() is true?
The precondition is subject to race conditions with weak_ptr::lock. Even if you get back a T* from shared_ptr<T>::release, you won't necessarily be able to destroy it properly since you have no idea where it points. It could be a pointer to a static object, a pointer to a base class without a virtual destructor, a pointer to a member of type T. If you want release(), shared_ptr is not the right tool. auto_ptr or unique_ptr offer release(). The problem today (in a pre-rvalue ref world) is that (a) we have no unique_ptr and (b) even if we had, vector< unique_ptr > still wouldn't work. I'd have expected ptr_vector<T> to be essentially an alias for vector< unique_ptr<T> > since there's obviously a need for that, but apparently it doesn't quite work that way.
Peter Dimov skrev:
Thorsten Ottosen wrote:
Hi!
Is there any smart_ptr and ptr_container that can transfer ownership of pointer, to avoid useless copy-construction and destruction of the object. I guess you can't release a shared_ptr, even though it's use count is
Seweryn Habdank-Wojewódzki skrev: 1. Peter, any reason for not having a release() given that its precondition is unique() is true?
The precondition is subject to race conditions with weak_ptr::lock. Even if you get back a T* from shared_ptr<T>::release, you won't necessarily be able to destroy it properly since you have no idea where it points. It could be a pointer to a static object, a pointer to a base class without a virtual destructor, a pointer to a member of type T. If you want release(), shared_ptr is not the right tool. auto_ptr or unique_ptr offer release().
ok.
The problem today (in a pre-rvalue ref world) is that (a) we have no unique_ptr and (b) even if we had, vector< unique_ptr > still wouldn't work. I'd have expected ptr_vector<T> to be essentially an alias for vector< unique_ptr<T> > since there's obviously a need for that, but apparently it doesn't quite work that way.
No, there are quite a few differences, although both allows you to move a pointer from the collection. Anyway, I understood our users problem as one needing a shared_ptr. If he can use std::auto_ptr, there is no problem AFAICT. -Thorsten
participants (3)
-
Peter Dimov
-
Seweryn Habdank-Wojewódzki
-
Thorsten Ottosen