Re: [boost] thread_specific_ptr<void>

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.
> http://msdn2.microsoft.com/en-us/library/ms682661.aspx
> 
> 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 
> specialize 
> 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
change there.

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

Anthony