As I mentioned in the chat yesterday, this looks really interesting. If I understand it correctly, then the CFFI library allows callbacks from C to Tcl - this was mentioned as a limitation for the dyncall backend, but not described in thedocumentation ;).
Regards,
Arjen
On Wednesday, April 6, 2022 at 5:15:41 AM UTC+2, apn wrote:documentation ;).
The cffi package permits calling C functions in shared libraries fromAs I mentioned in the chat yesterday, this looks really interesting. If I understand it correctly, then the CFFI library allows callbacks from C to Tcl - this was mentioned as a limitation for the dyncall backend, but not described in the
within Tcl scripts via either the libffi or dyncall open source libraries. >>
The cffi package permits calling C functions in shared libraries from
within Tcl scripts via either the libffi or dyncall open source libraries.
libffi is also used in the Python standard library - the module "ctypes" allows Python users to interface to any C library, including callbacks,
which is heavily used to build extensions at the script level, without a
C compiler. It is quite interesting to have the same thing for Tcl.
Christian
cffi came about for two reasons - for a long while libffi did not
support Win64 (I'm talking a decade or more ago) so twapi made use of dyncall. That eventually lead to cffi. Second, I felt scripting using a
C API needed more safety as well as convenience features. Hence cffi.
Adding libffi support in addition to dyncall was just the logical next step.
Anyone wrapping C API's should look at both ffidl and cffi and decide
for themselves. I'd obviously be biased no matter how much I claim
otherwise :-)
/Ashok
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 463 |
Nodes: | 16 (2 / 14) |
Uptime: | 156:57:22 |
Calls: | 9,384 |
Calls today: | 4 |
Files: | 13,561 |
Messages: | 6,095,919 |