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
We had a request to do this at Google, but it's not quite possible now: you could create a Buffer with a custom alloc/free fn pair, where the alloc does nothing and the free releases your memory... but since the free fn is a naked C fn ptr, you may or may not be able to release the memory since you might need a context to do so. (Also, we don't have an API that takes an existing ptr for data and also sets to alloc/free fns so you'd have to hack those in manually.)
Perhaps the simplest answer is to upgrade the alloc/free fns to be std::function to allow for lambdas, but that would slightly increase the size of every Buffer, since sizeofstd::function is typically sizeof(void*)*4 IIRC.
(The user found a workaround -- wrapping the Buffer in a unique_ptr with a custom deallocator -- so this isn't an essential fix.)
The text was updated successfully, but these errors were encountered:
We had a request to do this at Google, but it's not quite possible now: you could create a Buffer with a custom alloc/free fn pair, where the alloc does nothing and the free releases your memory... but since the free fn is a naked C fn ptr, you may or may not be able to release the memory since you might need a context to do so. (Also, we don't have an API that takes an existing ptr for data and also sets to alloc/free fns so you'd have to hack those in manually.)
Perhaps the simplest answer is to upgrade the alloc/free fns to be
std::function
to allow for lambdas, but that would slightly increase the size of every Buffer, since sizeofstd::function is typically sizeof(void*)*4 IIRC.(The user found a workaround -- wrapping the Buffer in a unique_ptr with a custom deallocator -- so this isn't an essential fix.)
The text was updated successfully, but these errors were encountered: