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?

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

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

"Bart van der Velden" <bartvelden@gmail.com> wrote in message news:eqp77k$1i8f$1@digitalmars.com...
> 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"?

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

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






  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?