Hi Matthew,
Wow! Thank you for the detailed response, and the saintly patience behind it.
In following your email, this is the working result after using '_pointer' in
the function signature:
(define instance-ptr (malloc _VkInstance))
(vkCreateInstance instcreateinfo #f instance-ptr)
(def
The short answer is: `(_ptr io _VkInstance)` does not mean that a
pointer to a `_VkInstance` happens on the Racket side. It means that a
`_VkInstance` (not a pointer to a `_VkInstance`) happens on the Racket
side, and a pointer to a `_VkInstance` happens on the C side.
Taking it from the top:
At
Thank you for taking the time. I am following you well enough, but I'm having
trouble applying your advice. I'll use a different function to hopefully
simplify the discussion.
typedef VkInstance_T* VkInstance;
VkInstance instance;
vkCreateInstance(&createInfo, NULL, &instance) // assume createIn
At Sun, 20 Oct 2019 23:07:58 +, 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
Hi Matthew,
That makes sense, thanks. I have a follow-up question, and forgive me for the
180-degree turn.
I realized I was wrong to convey that I want the wrapper functions to help with
allocations. My situation is that I have 346 generated procedure bindings for
Vulkan, and 1342 bindings tot
I don't think `ffi/unsafe` can generate that kind of wrapper for you.
I'd write something like this:
(define-vulkan vkEnumerateInstanceLayerProperties/private
(_fun (o0 : (_ptr io _uint32_t))
_pointer
-> (r : _VkResult)
-> (begin
(check-vkResult r 'vkEn
Consider the following C++ that calls a function once to learn how much it
should allocate for a vector, and again to populate said vector.
uint32_t count;
vkEnumerateInstanceLayerProperties(&count, NULL);
std::vector properties(count);
vkEnumerateInstanceLayerProperties(&count, properties.dat
7 matches
Mail list logo
