From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-01-08 06:42:25
Edd Dawson <lists <at> mr-edd.co.uk> writes:
> Hi Anthony,
> Anthony Williams wrote:
> > Edd Dawson <lists <at> mr-edd.co.uk> writes:
> >> Currently one cannot create a thread_specific_ptr<void> as the return type
> >> of
> >> thread_specific_ptr<void>::operator* would be void&.
> > It might be worth adding a specialization of thread_specific_ptr to handle
> > void
> > data, but I don't think that traits would be the way to do it, as it adds
> > lots
> > of complexity for not much gain.
> > However, this still begs the question: why?
> Win32 Fibers is my specific use-case. They're represented by pointers-to-void.
> I'm currently using thread_specific_ptr<int> with a little casting here or
> there. It works fine, but it just feels a little dirty.
OK. The way thread_specific_ptr works, it is designed to store a pointer to the
data you're really storing, so if you're storing a void*, you use
thread_specific_ptr<void*>. Of course, this just adds an extra layer of
complexity, and seems a bit daft if what you're storing IS a pointer.
I take it you're being careful to specify a suitable cleanup function, so your
app doesn't try and use "delete" on your fiber handle.
> I don't know if you took a look at shared_ptr_traits<>, but the only trait in
> there is "reference". It would be much simpler to do it this way than
> the entire class, IMO.
> But I'm happy to go either way, if you think it's worth the effort.
thread_specific_ptr itself isn't exactly complicated --- it just forwards
everything to the backend functions. The specialization wouldn't require any
> Incidentally, I just noticed today that there's threads-specific list. Would
> this best be discussed on there? If so, my apologies for the noise.
Either list is fine by me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk