From: Edd Dawson (lists_at_[hidden])
Date: 2008-01-08 13:07:19
Hi Anthony,
Anthony Williams wrote:
>>> 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.
Ah I see.
> 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.
Yes, I believe I was doing this part properly.
>> 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.
>
> thread_specific_ptr itself isn't exactly complicated --- it just forwards
> everything to the backend functions. The specialization wouldn't require any
> change there.
Regardless, it doesn't seem worth it now that you've explained how my usage
isn't particularly idiomatic!
Thanks,
Edd