Fix for shared handles for pool deleter #1925
Conversation
|
@asuessenbach Is it ok to leave it at that? |
|
I think, just using that check could result in a resource leak, as allocated command buffers would not be freed. Besides that: You might have modified your vk.xml, somehow. The And a side question: is it somehow assured or verified, that the CommandPool passed into the SharedCommandBuffer constructor is the very same that is used to actually allocate the CommandBuffer? |
Template magic it is then.
No way unfortunately, only if we had functions to make shared handles. In such case there would need to be all of the functions for shared handles. I dropped that idea, because both approaches looked inconvenient and ugly (operator-> and raw functions) |
added special constructor for pool types
|
Ok, so I added the magic, should not compile without the explicit pool argument now |
vulkan/vulkansc_shared.hpp
Outdated
| @@ -346,8 +346,8 @@ namespace VULKAN_HPP_NAMESPACE | |||
| public: | |||
| void destroy( DestructorType parent, HandleType handle ) const VULKAN_HPP_NOEXCEPT | |||
| { | |||
| VULKAN_HPP_ASSERT( m_destroy && m_dispatch ); | |||
| ( parent.*m_destroy )( handle, m_allocationCallbacks, *m_dispatch ); | |||
| if ( m_destroy && m_dispatch ) | |||
There was a problem hiding this comment.
Would you mind to run the generation for vulkansc as well?
There was a problem hiding this comment.
About that, what do you think about making github action for generating the code on PR merge to master?
There was a problem hiding this comment.
Ah, I saw, there is one already :D
|
@asuessenbach So, what do you think, can it be merged? |
|
Looks good now! |
No description provided.