Re: [Boost-users] Suggestion for boost`s smart pointers

-----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.

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

David Klein wrote:
so are there any objections about adding this feature to scoped_ptr?
I'm sure I have seen this discussion before. I believe the issue was the size of scoped_ptr itself. It is supposed to be a lightweight object, no bigger than the pointer it holds. Any added overhead is unacceptable. If you can implement the feature without adding any data members, fine. Otherwise, please create a new class. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

On Nov 29, 2006, at 10:33 AM, Richard Hadsell wrote:
David Klein wrote:
so are there any objections about adding this feature to scoped_ptr?
I'm sure I have seen this discussion before. I believe the issue was the size of scoped_ptr itself. It is supposed to be a lightweight object, no bigger than the pointer it holds. Any added overhead is unacceptable. If you can implement the feature without adding any data members, fine. Otherwise, please create a new class.
<nod> This comes up now and then.
Fwiw, anyone/everyone is welcome to my emulation of the proposed C+
+0X unique_ptr:
http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html
Sorry, it isn't documented. Here's the best documentation I
currently have:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/
n1856.html#Addition%20-%20Class%20template%20unqiue_ptr
The (non)copyright at the top means you can do whatever you want with
the code, including stripping my name out of it.
In a nutshell:
* It has a deleter.
* If the deleter is an empty class, sizeof(unique_ptr

Howard Hinnant wrote:
* It has cute syntax to safely handle arrays: unique_ptr
. * You can also customize the storage type (defaults to T*) by giving your deleter an optional D::pointer type.
Do you have a rationale/use cases for D::pointer and unique_ptr

On Nov 29, 2006, at 11:07 AM, Peter Dimov wrote:
Howard Hinnant wrote:
* It has cute syntax to safely handle arrays: unique_ptr
. * You can also customize the storage type (defaults to T*) by giving your deleter an optional D::pointer type. Do you have a rationale/use cases for D::pointer and unique_ptr
?
Not written up.
But D::pointer was put in in an attempt to support shared memory. In
this use case you really need a smart pointer instead of a T*. This
use case hasn't been tested with actual code. However the feature is
about as free as it gets. It consumes no code size or run time. And
the author of D can completely ignore the pointer type and not even
provide it. unique_ptr searches D, and if pointer isn't found, uses
T*. Put this one in the "might be useful, costs nothing to provide"
category.
On unique_ptr

Howard Hinnant wrote:
The motivation for unique_ptr
is so that vendors can offer range checking on operator[](size_t i) (perhaps only in debug builds). The N is a compile time constant, so takes up no storage space. The main cost is potential code bloat as you'll get a different instantiation for every different N. But if you don't use unique_ptr (but instead use only unique_ptr ) then you don't pay for this feature. Oh, and though most deleters don't need to know the size of the allocation, some might. So unique_ptr
calls D(pointer, N). The default D ignores the N.
Thanks. This is somewhat implementation-oriented, though. I was trying to
imagine use cases for T[N]. In what situations I would use it? A fixed-size
buffer on the heap... it can make sense at times, but it's hard to squeeze
it between array<>, vector<> and unique_ptr

On Nov 29, 2006, at 12:36 PM, Peter Dimov wrote:
I'm not interested in how free it is, just in how useful it is. :-)
<nod> If I were to scale usefulness as:
1. Would never use it.
2. ...
3. Might use it once in a while.
4. ...
5. I'd find it handy sometimes.
6. ...
7. ...
8. Lots of uses for it.
9. ...
10. Have to have it.
It might go something like:
unique_ptr<T> : 10
unique_ptr
participants (6)
-
David Klein
-
Howard Hinnant
-
Maitre Bart
-
Peter Dimov
-
Richard Hadsell
-
Sohail Somani