This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [smart containers] _M_clear()
- From: "Phil Bouchard" <philippe at fornux dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sat, 27 Sep 2008 15:37:42 -0700
- Subject: Re: [smart containers] _M_clear()
- References: <465FB007227B44139AB76BB74276787D@FORNUX> <3d6744d10809261131t21e9a127rf4ef8fffdeb425a6@mail.gmail.com> <3d6744d10809261132i7959440fu8ee41a9e5165c077@mail.gmail.com>
"Bob Walters" <bob.s.walters@gmail.com> wrote in message
3d6744d10809261132i7959440fu8ee41a9e5165c077@mail.gmail.com">news:3d6744d10809261132i7959440fu8ee41a9e5165c077@mail.gmail.com...
> Phil,
>
> I was thinking about your original proposal to have release() get
> called from within the clear() method. With your particular pointer,
> can the assignment "ptr = NULL;" have the same effect as calling
> release() ? I was thinking that such assignments could be added to
> the container code after the call to deallocate(). Your pointer would
> see that call, could confirm that ref counts on the set have dropped
> to 0, and release() their current contents. Obviously, that code
> would work equally well for standard pointers as well as smart ones.
>
> If that doesn't help with your particular case, then I agree we could
> just use what you've done in your note as an alternative. I remember
> you had some minor concerns about having to write your allocator with
> a deallocate() method that takes the pointer by reference, and thought
> this might eliminate the need for that.
If the pointer type is closely tied to the allocator it abstracts everything
better and keeps the current code simpler. The allocator already needs to
be aware of the pointer type and gives it more control by having pointers
passed in as references.
The raw pointers version of the functions can also be explicitly
instanciated inside the library so that the ABI isn't changed at all.
_Pointer_adaptor can be therefore used for get() and set() operations only.
-Phil