Re: How do I represent a convenient two-step allocation using ffi/unsafe?

At Sun, 20 Oct 2019 23:07:58 +0000, Sage Gerard wrote:
> So if I take the `vkEnumerateInstanceLayerProperties/private` you showed me 
> and change the (_ptr io _uint32_t) to (_cpointer _uint32_t), will it have any 
> other noticeable usability differences for someone thinking like a C 
> programmer? Do I have to use _ptr at all to do what I intend to do?

You don't have to use `_ptr`, but `(_cpointer _uint32_t)` is awkward,
because it requires that the allocated pointer is tagged using
`_uint32_t`. Then, instead of just

 (malloc _uin32_t)

a client would have to write

 (let ([p (malloc _uint32_t)])
   (cpointer-push-tag! p _uint32_t)
   p)

To expose the raw API without `_ptr`, I'd just use `_pointer`.

If possible, using `_ptr` is the right way to expose this function
without trying to provide a higher-level interface:

 (define-vulkan vkEnumerateInstanceLayerProperties
   (_fun (o0 : (_ptr io _uint32_t))
         _pointer
         -> (r : _VkResult)
         -> (begin
              (check-vkResult r 'vkEnumerateInstanceLayerProperties)
              o0)))

I don't know if the information you're working with lends itself to
generating that kind of view, though, which would mean describing the
first argument is an in--out `uint32_t`.

-- 
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5daceca8.1c69fb81.fc25d.ced3SMTPIN_ADDED_MISSING%40mx.google.com.