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