Re: How do I represent a convenient two-step allocation using ffi/unsafe?
Sage Gerard <sage-nnKKxiom5Z1/[email protected]>
| Newsgroups | gmane.comp.lang.racket.user,gmane.lisp.scheme.plt |
|---|---|
| Message-ID | <uve4UrxotdFfO-qPP633LXmJHb-OLnhG9iSwyZ2Cf3Lck9P6OcmxKFGzoG0VkzNQHKXesDMV6nRwOX72kNWStmUrLGkFAUQ2wX2wgtqvheo=@sagegerard.com> |
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 total. The more "helpful" the bindings I generate, the more differences I have to document, the more corner cases I have to support in the code generator, and the higher the learning curve for my users. I think it would be wiser to keep the bindings entirely consistent with their C equivalents and hand-write helpers on top to capture common patterns. 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? ~slg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, October 20, 2019 9:10 AM, Matthew Flatt mflatt-sDh8Nw2yj/[email protected] wrote: > 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 'vkEnumerateInstanceLayerProperties) > o0)) > > > #:c-id vkEnumerateInstanceLayerProperties) > (define (vkEnumerateInstanceLayerProperties) > (define len (vkEnumerateInstanceLayerProperties/private 0 #f)) > (define props (malloc _VkLayerProperties len)) > (define new-len (vkEnumerateInstanceLayerProperties/private len props)) > (values new-len props)) > At Sun, 20 Oct 2019 03:47:52 +0000, Sage Gerard wrote: > > > 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<VkLayerProperties> properties(count); > > vkEnumerateInstanceLayerProperties(&count, properties.data()); > > Below is my generated signature so far. The docs for > > [_list](https://docs.racket-lang.org/foreign/foreign_procedures.html?q=fun#( > > form.%28%28lib._ffi%2Funsafe..rkt%29.__list%29%29) shows similar examples,but they assume either the length of the vector is known in advance. > > How would I make a custom function type to manage both o1 and o0 values with > > the garbage collector, call the function twice as described, and return the > > value for o1 in a single call? > > (define-vulkan vkEnumerateInstanceLayerProperties > > (_fun (o0 : (_ptr o _uint32_t)) > > (o1 : (_ptr o _VkLayerProperties)) > > -> (r : _VkResult) > > -> (begin (check-vkResult r (quote vkEnumerateInstanceLayerProperties)) > > (values o0 o1)))) > > ~slg > > > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > 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/Vo2OHZYjsSlsnJojlfmw5yolaYJWQzql > > unk7S24hrnFb4Lk1jz0kqe2RCGM_aPFXxeVQfRqDPM2p7GKeN_drxRoi2Q9ZGu2srPhAme7LCAk%3D% > > 40sagegerard.com. -- 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/uve4UrxotdFfO-qPP633LXmJHb-OLnhG9iSwyZ2Cf3Lck9P6OcmxKFGzoG0VkzNQHKXesDMV6nRwOX72kNWStmUrLGkFAUQ2wX2wgtqvheo%3D%40sagegerard.com.