1

Do VkObjects need to be nulled, or is it solved somehow in automatic way?

  • For example when I have Buffer class which is wrapper for
VkBuffer _buffer;

and destructor like this:

Buffer::~Buffer()
{
  vkDestroyBuffer(_device.getLogicalDevice(), _buffer, nullptr);
  if(_memory) {
    vkFreeMemory(_device.getLogicalDevice(), _memory, nullptr);
  }
}

Do I need to set, after destructor is called, _buffer to VK_NULL_HANDLE or nullptr or it is not necessary and this is done in automatic way?

(Basically what is my question is if specification stands in which state is left the object instance after calling vkDestroyXYZ / vkFreeXYZ)

And if yes, it applies for all VkObjects (like VkInstance, VkImage, etc.) or there are some exceptions?

I thought I am pretty OK if I left the object as it is (especially when it is immediately destroyed after), but we come to this discussion during the code review and lets say, that my reviewer has set -pedantic and -Wall for the sake of our code base I must admit :)

CJ_Notned
  • 248
  • 2
  • 11
  • This seems to be roughly equivalent to setting an ordinary pointer to null after deleting it, which is completely unnecessary if it's a member variable inside a destructor. Unless `_buffer` is somehow used by reference elsewhere (which would probably be a code smell), your code seems completely fine. See also https://stackoverflow.com/questions/3060006/is-it-worth-setting-pointers-to-null-in-a-destructor – alter_igel Nov 19 '20 at 18:34

1 Answers1

4

When you have (properly) destroyed a Vulkan object, it is destroyed. That's the end of it. It's no different from destroying an object in C++ through its pointer: the object being pointed to is gone.

What you do with the pointer value itself is up to you (outside of passing its value as input to Vulkan APIs, which of course you can't do).

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982