Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-30 11:22:18

From: William Kempf <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >From: "William Kempf" <williamkempf_at_[hidden]>
> >> >I don't see this in thread_specific_ptr.html.
> >>
> >>Quoted from the introduction in thread_specific_ptr.html:
> >>
> >>"Template thread_specific_ptr stores a pointer to an object obtained via
> >>new
> >>on a thread-by-thread basis and deletes the object when a thread
> >>terminates."
> >
> >The statement makes perfect sense to me now when I already know what it's
> >supposed to mean, but I somehow managed to miss its significance on the
> >first - and two subsequent - readings. ;-)
> Help me out then :). I thought this was fairly clear, and there was
> supporting wording elsewhere in the document as well. If this wasn't clear
> then how can I change the documentation to make it clear?
> >The reference section doesn't mention that thread_specific_ptr calls
> >'delete' on the contained pointer on thread exit, though. Only on reset>().
> Where, within the reference, could I mention this? None of the methods
> exposed in the interface deal with this event. The fact that reset()
> requires a pointer to an object created through "new" is a strong indicator,
> but I understand that this doesn't fully cover things. I can add the text
> in reset() indicating that the object is deleted on thread termination, but
> I modeled this off the documentation for std::auto_ptr where they don't make
> mention of deletion when the object is destroyed.


  ~auto_ptr() throw();

    The expression delete get() is well formed.
    delete get().

> I'm not sure it's
> appropriate to reference this future event here or not.

> >BTW, you've done a great job!


> >I took a look at the implementation of
> >thread_specific_ptr and was impressed. It's even possible to implement a
> >cleanup handler list with it (although it'd probably be simpler to expose
> >the internal cleanup handler support.)
> One question and one comment. Do you mean "cleanup handler" or "cleanup
> stack"? They are seperate concepts in POSIX, and the "cleanup handler" is
> fully an implementation detail. There's no need for any other type of
> cleanup handling beyond that given by the implementation. "cleanup stacks"
> on the other hand are a fully different concept, and I don't think they're
> that useful in C++ where we have destructors that perform the same purpose.
> My comment is that the "cleanup handler" isn't fully exposed because it's
> not a type safe operation and I couldn't think of a mechanism to make it so.
> As an implementation detail the type safety is a non-issue, since the
> implementation is gauranteed type safe.
> Oh, on reflection I also suppose when you say "cleanup handler" you may mean
> a concept similar to atexit() but for threads. I considered a
> thread::atexit(), and likely will include one in the future since it's
> trivial functionality, but I wanted to keep the interface to a minimum for
> the initial submission.
> Bill Kempf
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> Info: Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at