Re: [boost] smart_ptrs: Custom allocators.

From: Murray Cumming (murrayc_at_[hidden])
Date: 2001-08-17 08:26:58

Peter Dimov wrote:
> 
> From: "Murray Cumming" <murrayc_at_[hidden]>
> > Peter Dimov wrote:
> > > The variant in shared_ptr_updates.zip can do
> > >
> > > shared_ptr<my_type> p(my_alloc(), &my_drop);
> >
> > No, I think that's enough because allocation/deallocation is rarely that
> > simple.
> >
> > For instance, for the freaky Sybase client library that I'm wrapping:
> >
> > - The allocation functions don't just return the instance. The instance
> > pointer is an input argument and the result is a success/error code.
> > - Some allocation functions require extra data/instances, so my smart
> > pointer has a non-default constructor that actually allows me to specify
> > an *instance* of an allocator. e.g.:
> 
> Can't you just wrap the creation function?
> 
> int sybase_create_connection(sybase_context * ctx, args);
> 
> sybase_context * my_create_connection(args)
> {
>    std::auto_ptr<sybase_context> ctx(new sybase_context);
>    int err = sybase_create_connection(ctx.get(), args);
>    throw_sybase_error_if(err);
>    return ctx.release();
> }

Sorry, I read that as 'address of myalloc', instead of 'myalloc()'. This
might be enough, though it's less flexible. In particular, a custom
allocator would allow more use of a deallocator function that took args.

> It's not as elegant as a dedicated smart handle class, granted. If you
> decide to go that route you'll find that detail/shared_count.hpp does most
> of the work for you. :-)

That's not very obvious to me.

-- 
Murray Cumming
www.murrayc.com
murrayc_at_[hidden]