4 ms·
I don't understand? Why would function pointers or member functions be involved in a plain C API (unless you want to create one of those ugly "let's wrap an OOP
by flohofwoe 4y ago
I don't understand? Why would function pointers or member functions be involved in a plain C API (unless you want to create one of those ugly "let's wrap an OOP C++ API in a C API" attempts where each C++ method maps to a C function with a "this" parameter or have "virtual function tables" - essentially emulating C++ in C, which really doesn't make much sense).
As for the memory safety aspects: When returning raw pointers to internal objects from an API, those pointers can become dangling.
C++ smart pointers are not a solution because those cannot be expressed through a C API for language bindings - also there's the question what type of smart pointer to return - unique vs shared? That should be up to the API user, not dictated by the API.
Tagged index handles solve all those problems in a very elegant way - and they work equally well for C, C++ or any other language that supports arrays, and since those handles are essentially just integers, they are trivial to tunnel through FFI (see for instance: https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html)
- pjmlp 4y agoIt is hardly better than having opaque handles that translate into C++ classes, with proper validation of invariants. I know how well they work in C, having worked on a RPC server for IVR/CRM middleware using similar approach for shared memory IPC across UNIX/Windows multiprocess, and having my share of fixing memory corruption issues in collaboration with our QA team nicely written attack tests in Rational Robot. I guess instead of using Purify and BoundsChecker, now the fun will be with ASAN.