thread_specific_ptr<void>
Hello, Currently one cannot create a thread_specific_ptr<void> as the return type of thread_specific_ptr<void>::operator* would be void&. So is there any technical reason that we cannot do the same trick as with shared_ptr? i.e. have operator* return a thread_specific_ptr_traits<T>::reference, which would be void in the thread_specific_ptr_traits<void> specialisation, allowing client code to compile so long as operator* is not called. I'd be happy to put a patch together (against the SVN trunk, I assume?). Kind regards, Edd
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&.
So is there any technical reason that we cannot do the same trick as with shared_ptr? i.e. have operator* return a thread_specific_ptr_traits<T>::reference
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? Anthony
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. 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. 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. Edd
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
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
participants (2)
-
Anthony Williams -
Edd Dawson