NS::SharedPtr/TransferPtr/RetainPtr

Question

Created Jul ’22

Replies 4

Boosts 0

Views 1.5k

Participants 3

I was watching the Metal-cpp video which mentions a C++ smart pointer wrapper to handle reference counting in Metal objects. I've been trying to write my own and the realization that this already existed made me want to try it, but it doesn't actually seem to exist. I can't remember if I installed the beta version or not. It wasn't immediately clear to me if I can identify which version of Metal-cpp I am using by looking inside the folders.

Should this exist?

On a somewhat related note I am having some issues trying to call retain on an MTL::TextureDescriptor object that was originally created with MTL::TextureDescriptor::alloc()->init(). This could just be my own bug, but I was wondering if I am misunderstanding how it works. In this case we have a mid level texture class that may want to recreate itself by altering the TextureDescriptor afterwards, but in some cases that texture was also created by a higher level texture class that also may want to do it's own version of the same thing and so it seemed prudent to just share the same TextureDescriptor object.

Boost

Answer 1

scarrow OP

Jul ’22

I think the breakpoint I was hitting was just that I forgot to actually return the value (damn you C++ for not just treating that as an error!).

0

Answer 2

endecotp OP

Jul ’22

-Werror=return-type might turn that into an error, if you're lucky.

0

Answer 3

endecotp OP

Jul ’22

Very interesting. I watched the video but haven't looked at the code yet. My initial reaction was that their approach to memory management seemed to be adding the worst of objC to C++, when they could have adopted "modern C++" memory management (i.e. unique_ptr, shared_ptr) for these classes.

0

Answer 4

OP

Apple

Jul ’22

Hi scarrow,

We introduced a new NS::SharedPtr<T> type in metal-cpp_macOS13_iOS16-beta. It is not available in previous releases of metal-cpp.

You can use this smart pointer in lieu of std::shared_ptr. It has the advantage that it internally leverages the ObjC facilities for reference counting, therefore avoiding an extra control structure and retain count that you would have if you used the standard library's non-intrusive shared_ptr. NS::SharedPtr<T> provides you with memory management facilities at no extra memory cost.

Regarding the MTL::TextureDescriptor, it is perfectly valid to use the descriptor object to create a texture and then modify and reuse it to create further texture objects. This is because Metal Textures are immutable objects after you create them, allowing you to safely modify the descriptor.

In your case, you may want to keep a pointer to the texture descriptor and then reuse it as needed. Just keep in mind that if several of your objects hold pointers to the same descriptor, then any changes to the descriptor are visible to all of your objects sharing the same pointer.

1