FW: [Boost-users] Suggestion for boost`s smart pointers
Hi, Please see the following email about additional template parameters for scoped_ptr. The quick hack I wrote for it is below (I've used this in previous project as well). I think it would be very useful to many users and wouldn't change any source using scoped_ptr. Thanks, Sohail ==== I've been thinking something like (just something I hacked together just now). Not sure if there is a nicer way. #include <string> #include <cstdio> #include <iostream> template<typename T> struct DeletingDeleter { DeletingDeleter(T * p) { delete p; std::cout << "DeletingDeleter" << std::endl; } }; struct FileCloser { FileCloser(FILE * f) { std::cout << "Closing file" << std::endl; fclose(f); } }; template<typename T, typename Deleter=DeletingDeleter<T> > struct scoped_ptr { scoped_ptr():p_(0){} scoped_ptr(T * p):p_(p){} ~scoped_ptr() { Deleter d(p_); } T * get() {return p_;} // regular stuff private: T * p_; }; typedef scoped_ptr<FILE,FileCloser> file_ptr; int main() { scoped_ptr<int> a; // maintain old interface scoped_ptr<int> b(new int(5)); file_ptr p(fopen("myfile.txt","w")); fprintf(p.get(),"Hello world!\n"); }
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of David Klein Sent: Tuesday, November 28, 2006 4:55 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Suggestion for boost`s smart pointers
Sohail Somani wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of David Klein
Sohail Somani wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of mark cox
wow, this seems like a great idea, a scoped_ptr with deleter would be v.useful. mark
I've been thinking something like (just something I hacked
together just
now). Not sure if there is a nicer way.
[snip]
+1 vote for this idea :)
i actually kind of did this for my current project, because i needed a custom deleter for scoped_ptr, when shared_ptr was to much overhead...
As did I, but it was not for performance but for readability. Shared pointers mean... Shared. Scoped don't. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
yep exactly, thatswhy i "ripped" scoped_ptr out of boost and added my custom_deleter stuff. (i only *thought* about shared_ptr to do the job)
so are there any objections about adding this feature to scoped_ptr?
-- regards dave
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sohail Somani wrote:
Please see the following email about additional template parameters for scoped_ptr. The quick hack I wrote for it is below (I've used this in previous project as well). I think it would be very useful to many users and wouldn't change any source using scoped_ptr.
This question makes me feel nostalgic. My first request on this list looked very similar (I needed to Release() COM objects). I just dug up the reply and it seems there used to be this kind of parametrized deletion for shared_ptr. I learned a lot about C++ design since then (not at least because of lurking in this unique and elite forum ;-) ) and I'd propose a different interface for that feature today: Actually, I don't think that parametrized deletion belongs into the interface of a smart pointer. It's up to other components to have proper deletion semantics. Still, there sure are cases (dealing with third-party or plain C components) where it is a practical thing to have. So I'd probably ask for a freestanding function that is called without qualification to do the deletion (just using delete by default), so it can be overloaded and found via ADL and we don't need to change and mess up the interface of the smart pointer. BTW. I just noticed there is some "get_deleter logic" (marked as experimental in a comment) based on RTTI in 'shared_ptr.hpp'. What's that all about? Heap selection when using shared libraries? Regards, Tobias
Tobias Schwinger wrote:
BTW. I just noticed there is some "get_deleter logic" (marked as experimental in a comment) based on RTTI in 'shared_ptr.hpp'. What's that all about? Heap selection when using shared libraries?
The comment is wrong, get_deleter is no longer experimental, it's part of TR1 and the C++0x working paper. Its main purpose is for a library to be able to recognize its own shared_ptrs when someone feeds them back to it. Boost.Python uses it to store a pointer to the original Python object in its deleters and do a correct roundtrip conversion.
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Tobias Schwinger Sent: Fri 12/1/2006 3:57 AM To: boost@lists.boost.org Subject: Re: [boost] FW: Suggestion for boost`s smart pointers Sohail Somani wrote:
Please see the following email about additional template parameters for scoped_ptr. The quick hack I wrote for it is below (I've used this in previous project as well). I think it would be very useful to many users and wouldn't change any source using scoped_ptr.
This question makes me feel nostalgic. My first request on this list looked very similar (I needed to Release() COM objects). I just dug up the reply and it seems there used to be this kind of parametrized deletion for shared_ptr. ---------------- Thanks for your reply but the domain of COM objects lends itself well to shared_ptr. ----------------- Actually, I don't think that parametrized deletion belongs into the interface of a smart pointer. It's up to other components to have proper deletion semantics. Still, there sure are cases (dealing with third-party or plain C components) where it is a practical thing to have. ------------------ I went through the archives after the posts and I have realized that scoped_ptr is not changing! I will still disagree that the deleter shouldn't be a parameterized type. The only other option is using a type erasure mechanism like shared_ptr which is more trouble than its worth for things like deallocating C resources.
Sohail Somani wrote:
Thanks for your reply but the domain of COM objects lends itself well to shared_ptr.
As to scoped_ptr. I don't quite understand the "but" in that sentence.
I went through the archives after the posts and I have realized that scoped_ptr is not changing! I will still disagree that the deleter shouldn't be a parameterized type.
What's wrong with: template<typename T> void free_resource(T* ptr) { delete ptr; } void free_resource(std::FILE* f) { std::fclose(f); } void free_resource(IDispatch * o) { o->Release(); } template<typename T> struct scoped_ptr { // [...] ~scoped_ptr() { free_resource(this->p_); } // [...] }; ?! Adding another dummy parameter will make ADL work (see attached file for demonstration of the technique).
The only other option is using a type erasure mechanism like shared_ptr which is more trouble than its worth for things like deallocating C resources.
I was referring to the file pointer, which is pretty much the only "C resource" I use. You're right when it comes to malloc/free, of course - but do we really need it? Regards, Tobias #include <iostream> namespace framework { enum adl_hook { use_adl }; template<typename T> inline void visit(T const & o, adl_hook) { std::cout << "default case" << std::endl; } } namespace my_prj { struct my_class { }; void visit(my_class const & x, framework::adl_hook) { std::printf("my_class\n"); } } int main() { int a = 1; my_prj::my_class b; visit(a, framework::use_adl); visit(b, framework::use_adl); return 0; }
participants (3)
-
Peter Dimov -
Sohail Somani -
Tobias Schwinger