How to use C library?

[ghost]

As with other none-C languages I think we have to make a binding, isn't it? But how?

I wanted to use this library: https://github.com/dbsoft/dwindows

[demoitem]

Yes you have to wrap dw.h but its a big file. You could do it by hand or use a tool
like swig. You have to weigh up the cost of learning something complex like
swig to the cost of slowly writing a binding for each #define and function declaration.

[mikanystrom]

If I may put in a few words here, just my own observations from using Modula-3 for over 20 years now... "Using a C library" can mean many things. One thing it can mean is "exporting all the definitions and mechanisms of the C library so that they can be used in Modula-3 pretty much the way you used them in C." This is a lot of work, and it is something I have done a few times, and something that you can see evidence of other people doing in the cm3 git repo here and there. My opinion, after doing this many times over, is that this is not usually what you want to do. Partly because it is a lot of work, but mostly because what you wind up with does not generally live happily inside the M3 system. The reason is, M3 is decades ahead of C in terms of the types of guarantees and facilities the runtime and language (type system, safety mechanisms, etc) provide. Using a C library usually forces you to work with it the way you would in C. Who allocated that object? Who is responsible for freeing it? Whoops, did I have to grab a pthreads mutex before I did that? Why am I getting bus errors all of a sudden? No, what you usually want to do is... work out a new abstraction in M3 that builds on top of whatever facilities you have in the C library. Make it a small, clean abstraction that does one or two things well. Don't make it a kitchen sink of "stuff vaguely related to XYZ." Then figure out how to implement that abstraction in a combination of M3 and C. And ignore the rest of the C library (interface/header file). A more concrete example is that well-written C libraries often provide synchronous and asynchronous (re-entrant) entry points. If that's the case, a powerful M3 pattern would be: make an OBJECT type that forks off a thread, and use the re-entrant entry point from the thread. Ignore the synchronous entry point. Don't let M3 clients call the C functions directly, make them call through the methods of your object type. A meta-observation is that because C is so clunky, C library writers often have to provide all sorts of DIFFERENT interfaces to the basic functionality of their code. Do you need something that can be re-entrant? Do you need something that allocates memory itself? Do you need something that is a macro instead of a function? Most of these variants are going to be completely uninteresting to an M3 programmer. Just don't need them. And don't translate #defines. Instead make stub functions that evaluate the constant at runtime and return it. Yes, there's an efficiency cost, but no, that cost will not be enough to make your program slower than Java (or, even worse, Python). A simple example of what I'm talking about: https://github.com/modula3/cm3/tree/master/caltech-other/mpfr/src It's a pretty incomplete translation of the source interface, but it's good enough to do real work! Mika P.S. when writing abstractions on top of C libraries, WeakRef.i3 is your friend.

…

On Thu, Sep 8, 2022 at 7:43 AM peter mckinna ***@***.***> wrote: Yes you have to wrap dw.h but its a big file. You could do it by hand or use a tool like swig. You have to weigh up the cost of learning something complex like swig to the cost of slowly writing a binding for each #define and function declaration. — Reply to this email directly, view it on GitHub <#1057 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKYNJM46LWLHH7UNEMGCU3V5H3R7ANCNFSM6AAAAAAQGIXQUU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>