VK_NULL_HANDLE is always 0; Why not nullptr? - c++

Question

In most cases, you can get away with assigning VK_NULL_HANDLE to any handle defined by VK_DEFINE_HANDLE(object) or VK_DEFINE_NON_DISPATCHABLE_HANDLE(object), but std::exchange() fails to set this value in almost all cases.
In most situations I have to call std::exchange(m_dispatchableHandle, nullptr) and std::exchange(m_nonDispatchableHandle, nullptr)
However, on x86, nullptr is invalid due to the redefinition of VK_DEFINE_NON_DISPATCHABLE_HANDLE. I must use std::exchange with NULL, 0, or (finally) VK_NULL_HANDLE.
My question: in following the VK_DEFINE_HANDLE macro patterns, should there not be two null handle macros defined like the following?
#define VK_NULL_HANDLE nullptr
#if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__) && !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__)
#define VK_NON_DISPATCHABLE_NULL_HANDLE nullptr
#else
#define VK_NON_DISPATCHABLE_NULL_HANDLE 0
#endif
If nothing else, it seems like #define VK_NULL_HANDLE nullptr would have more utility in general.
I may be misunderstanding how the API is supposed to be used, so I'm sharing the trouble code in question: a move constructor that transfers handles and fills the old object with NULL or VK_NULL_HANDLE. By carefully managing ownership, the class can be designed simply and handle vkDestroy* et. al. in its destructor.
class RenderContext
{
public:
RenderContext(VkPhysicalDevice physicalDevice, uint32_t gfxQueueFamilyIdx, uint32_t presentQueueFamilyIdx);
RenderContext(const RenderContext& other) = delete;
RenderContext& operator=(const RenderContext& other) = delete;
RenderContext(RenderContext&& other) noexcept;
RenderContext&& operator=(RenderContext&& other) = delete;
~RenderContext();
private:
VkDevice _device;
VkCommandPool _gCmdPool;
VkCommandPool _pCmdPool;
VkQueue _gQueue;
VkQueue _pQueue;
};
RenderContext::RenderContext(VkPhysicalDevice physicalDevice, uint32_t gfxQueueFamilyIdx, uint32_t presentQueueFamilyIdx) :
_device(VK_NULL_HANDLE),
_gCmdPool(VK_NULL_HANDLE),
_pCmdPool(VK_NULL_HANDLE),
_gQueue(VK_NULL_HANDLE),
_pQueue(VK_NULL_HANDLE)
{
// ...
}
RenderContext::RenderContext(RenderContext&& other) noexcept :
_device(std::exchange(other._device, nullptr)),
_gCmdPool(std::exchange(other._gCmdPool, VK_NULL_HANDLE)),
_pCmdPool(std::exchange(other._pCmdPool, VK_NULL_HANDLE)),
_gQueue(std::exchange(other._gQueue, nullptr)),
_pQueue(std::exchange(other._pQueue, nullptr))
{}
RenderContext::~RenderContext()
{
vkDestroyCommandPool(_device, _pCmdPool, nullptr);
vkDestroyCommandPool(_device, _gCmdPool, nullptr);
vkDestroyDevice(_device, nullptr);
}

Answer 1

Templates in C++ require precise type, not just compatible one, to properly instantiate. As such C's NULL (defined as 0) might be a problem. 0 might also be a problem as it is int, not uint64_t, which is the ABI of Non-dispatchable Handles (which can be stored in 64 bit pointer to get some type safety out of C). This is not new when dealing with C libraries from C++ (or generally).
Rest is design questions and suggestions adressed at authors, and as such unsuitable for StackOverflow. The issue tracking system is available at https://github.com/KhronosGroup/Vulkan-Docs/issues. On the face, your suggestion makes sense to me. They probably do not want to make it pervasive, but additionally, it might be a case for doing #ifdef __cplusplus #define VK_NULL_HANDLE nullptr.
Alternatively, there is Vulkan-Hpp, which is supposed expose more C++-istic bindings to Vulkan.
Proper way currently to call the template function would be std::exchange(m_nonDispatchableHandle, decltype(m_nonDispatchableHandle)(VK_NULL_HANDLE));.

Answer 2

In most cases, VK_NULL_HANDLE can be assigned to any handle defined by VK_DEFINE_HANDLE(object) or VK_DEFINE_NON_DISPATCHABLE_HANDLE(object)
Wrong. You can get away with it because C and C++ let you. But the Vulkan specification is very clear:
The reserved values VK_NULL_HANDLE and NULL can be used in place of valid non-dispatchable handles and dispatchable handles, respectively
That is, VK_NULL_HANDLE is only for non-dispatchable handles. That the C/C++ languages allow you to assign the value of VK_NULL_HANDLE to a dispatchable handle is merely a function of the language, and the behavior for Vulkan itself is not defined.
You should never be trying to std::exchange between a dispatchable handle and a non-dispatchable handle, just as you should never be trying to std::exchange between two distinct types.