c++.stlsoft - Thief constructor for scoped_handle?
- Matthew Wilson (11/11) Feb 08 2007 I've been mulling over some ideas for scoped_handle, in particular the i...
- Bart van der Velden (5/23) Feb 12 2007 I have not used nor studied scoped_handle at all, but the question comes
- Matthew Wilson (16/38) Feb 16 2007 idea of one instance being able to "take over" the management of a resou...
- Adi Shavit (20/32) Feb 12 2007 My $0.02.
- Matthew Wilson (42/42) Feb 16 2007 charset="iso-8859-1"
I've been mulling over some ideas for scoped_handle, in particular the idea of
one instance being able to "take over" the management of a resource being
managed by another instance.
Consider:
{
stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free);
if(some-condition)
{
stlsoft::scoped_handle<void*> sh2(&sh1);
} // if "some-condition", memory is freed here
} // if "!some-condition", memory is freed here
It'd be very simple to implement.
Thoughts?
Feb 08 2007
Matthew Wilson wrote:
I've been mulling over some ideas for scoped_handle, in particular the idea of
one instance being able to "take over" the management of a resource being
managed by another instance.
Consider:
{
stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free);
if(some-condition)
{
stlsoft::scoped_handle<void*> sh2(&sh1);
} // if "some-condition", memory is freed here
} // if "!some-condition", memory is freed here
It'd be very simple to implement.
Thoughts?
I have not used nor studied scoped_handle at all, but the question comes
to mind what would happen when you access sh1 after the memory is freed
in the case of "some condition"?
Bart
Feb 12 2007
"Matthew Wilson" <matthew hat.stlsoft.dot.org> "Bart van der Velden" <bartvelden gmail.com> wrote in message news:eqp77k$1i8f$1 digitalmars.com...Matthew Wilson wrote:idea of one instance being able to "take over" the management of a resource being managed by another instance.I've been mulling over some ideas for scoped_handle, in particular theWell, that would be just the same as if you'd written: { stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free); if(some-condition) { stlsoft::scoped_handle<void*> sh2(sh1.get(), ::free); } // if "some-condition", memory is freed here } // if "!some-condition", memory is freed here The difference is that you don't have the DRY SPOT violation of having to specify ::free twice. It's just a safe (because it takes the address) syntactic nicety that protects against maintenance.Consider: { stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free); if(some-condition) { stlsoft::scoped_handle<void*> sh2(&sh1); } // if "some-condition", memory is freed here } // if "!some-condition", memory is freed here It'd be very simple to implement. Thoughts?I have not used nor studied scoped_handle at all, but the question comes to mind what would happen when you access sh1 after the memory is freed in the case of "some condition"?
Feb 16 2007
My $0.02.
I think what you are describing is similar to ScopeGuard
<http://www.ddj.com/dept/cpp/184403758>.
It is somewhat equivalent to "release at destruction unless released
previously (or told not to)", though it does both releases automatically
(via the resp. destructors.)
I always though of scoped_handle as a more practical and general boost::
<http://www.boost.org/libs/smart_ptr/scoped_ptr.htm>scoped_ptr<>
<http://www.boost.org/libs/smart_ptr/scoped_ptr.htm>.
It allows a non-delete release function.
In this sense you would be breaking away from the scoped_ptr interface
(not necessarily a bad thing), but it, sort of, goes against the simple
spirit of scoped_handle (and scoped_ptr).
I see that it might be useful in various situations, but I think the
syntax should be more verbose, no?
Adi
P.S.
C++2x will finally have a proper policy based smart_ptr<> that will
support all of these ideas and many more. Yippy... :-P
Matthew Wilson wrote:
I've been mulling over some ideas for scoped_handle, in particular the idea of
one instance being able to "take over" the management of a resource being
managed by another instance.
Consider:
{
stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free);
if(some-condition)
{
stlsoft::scoped_handle<void*> sh2(&sh1);
} // if "some-condition", memory is freed here
} // if "!some-condition", memory is freed here
It'd be very simple to implement.
Thoughts?
Feb 12 2007
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It does go against the spirit somewhat, but I think the reduction in DRY =
SPOT violation (mentioned in other response to Bart) makes it at least =
worth considering.
I'm not convinced by any means - which is why I was soliciting opinion - =
but I think it's worth exploring, so I think I'm going to put it in, but =
marked "subject to change" or something.
"Adi Shavit" <adish gentech.co.il> wrote in message =
news:eqpf7b$1sj5$1 digitalmars.com...
My $0.02.
I think what you are describing is similar to ScopeGuard.
It is somewhat equivalent to "release at destruction unless released =
previously (or told not to)", though it does both releases automatically =
(via the resp. destructors.)
I always though of scoped_handle as a more practical and general =
boost::scoped_ptr<>.
It allows a non-delete release function.
In this sense you would be breaking away from the scoped_ptr interface =
(not necessarily a bad thing), but it, sort of, goes against the simple =
spirit of scoped_handle (and scoped_ptr).
I see that it might be useful in various situations, but I think the =
syntax should be more verbose, no?
Adi
P.S.
C++2x will finally have a proper policy based smart_ptr<> that will =
support all of these ideas and many more. Yippy... :-P=20
Matthew Wilson wrote:
I've been mulling over some ideas for scoped_handle, in particular the =
idea of one instance being able to "take over" the management of a =
resource being managed by another instance.
Consider:
{
stlsoft::scoped_handle<void*> sh1(::malloc(10), ::free);
if(some-condition)
{
stlsoft::scoped_handle<void*> sh2(&sh1);
} // if "some-condition", memory is freed here
} // if "!some-condition", memory is freed here
It'd be very simple to implement.
Thoughts?
Feb 16 2007