You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are use cases where storing a Ptr a makes sense and the caller will clean up the memory when done with it. For example, if the caller has a ForeignPtr already you might see code like this:
withForeignPtr ptr $ \p -> do
let pd = PixelData ... p
...
Here, the withForeignPtr will clean up p when done with it and pd should not escape (it is undefined outside of withForeignPtr).
I could also imagine a case where the PixelData is created outside of a withForeignPtr and the creator wants to associate a finalizer with the pointer stored inside. For this reason it may make sense to have a variant of PixelData that supports ForeignPtr.
The text was updated successfully, but these errors were encountered:
There are use cases where storing a
Ptr a
makes sense and the caller will clean up the memory when done with it. For example, if the caller has aForeignPtr
already you might see code like this:Here, the
withForeignPtr
will clean upp
when done with it andpd
should not escape (it is undefined outside ofwithForeignPtr
).I could also imagine a case where the
PixelData
is created outside of awithForeignPtr
and the creator wants to associate a finalizer with the pointer stored inside. For this reason it may make sense to have a variant ofPixelData
that supportsForeignPtr
.The text was updated successfully, but these errors were encountered: