ImportC Rox

The main application in the suite of financial tools I built for myself and ported to D from C uses the gtk3 and sqlite3 C libraries. Let's talk about gtk, which is a big system and has many convoluted and complex header files.

I dealt with gtk in my D code as you might expect. I created a gtk.d with hand-coded definitions and function prototypes such as

alias gconstpointer = immutable(void) *;

struct GtkWindow; // All structs that are dealt with by pointer only are defined this way

struct GtkTreeIter {
    long[4] dontcare;
} /* A few structs like this need to be stack-allocated in D code, their addresses
     passed to gtk functions. I check their sizes against globals containing
     sizeofs in a the lone C file that is part of this application */

extern (C) void gtk_tree_selection_select_iter(GtkTreeSelection* selection, GtkTreeIter* iter);

This is the standard pre-ImportC approach. Messy and ugly, but it works. However, if the library functions and C header files change, the application will break in unpredictable and hard-to-debug ways. At the moment, I'm using gtk3, which will not change because they've moved on to gtk4 with a somewhat different API. But if I decide to update to gtk4, I would be subject to this risk using this method.

I read the ImportC documentation when it first became available and several times since. I did not come away from those readings with a clear idea of how to use it to rid myself of the above. Then I saw Walter's comment in the link above. Aha -- you can just import header files in D code! The documentation does not say that, unless I've missed something. I think the relevant section is 41.3.2, which, given 'import hello', says "which will, if hello is not a D file, and has an extension .i or .c, compile hello with ImportC". No mention of .h files. Walter's comment made two things clear -- how to use ImportC in my case and that the documentation needs to be corrected and improved with an example of importing a C header file. Importing header files so you can directly use C libraries is a major reason why ImportC is an important addition to D and it should be crystal clear in the documentation how to do it.

With my improved understanding, I decided to give ImportC a try. All my D source files already had 'import gtk' statements, to get at my hand-coded definitions above. So no change was needed, since the goal was now to import gtk.h. I simply changed my makefile for this application to, in the invocations of dmd that compile my D source files, include the standard pkg-conf call that expands primarily into '-I's, indicating where to find all the gtk header files. A little post-processing of that expansion was necessary with sed, because dmd expects -I in a slightly different format than clang. I also needed to remove a couple of switches that dmd doesn't support.

I also removed the checks on struct sizes (and their definitions in my C file), since the struct definitions are now available directly from the Gtk header files.

Then I got rid of all references in the makefile to my gtk.d source file. After a few false starts due to things I overlooked, the application built successfully. This all took less than an hour. I've done some cursory testing and it seems to work properly. I was quite amazed at how easy this was.

So based on my initial experience, Walter's statement about ImportC's usefulness seems to be correct (I will report if anything turns up in more thorough testing) and I congratulate him for this work; it really facilitates the use of C libraries. I think this should be prominent in any "Why D?" presentation or discussion, because ImportC greatly enhances D's competitive position, in my opinion. Marketing!

I will add that I've played with zig a bit, starting a couple of years ago, attracted by its translate-c capability, which is analogous to ImportC. At that time, I remember looking at D as a candidate for the work I wanted to do and being put off by the realization that to use it, I would need to do something like the above hackery. I did eventually come back to D despite this, because Zig was and is not ready and because of my misadventures with Rust, which I've already discussed in other posts.

On Wednesday, 9 November 2022 at 15:00:39 UTC, Don Allen wrote:

On Monday, 7 November 2022 at 22:05:38 UTC, Walter Bright wrote:

https://news.ycombinator.com/item?id=33509223

I read the ImportC documentation when it first became available and several times since. I did not come away from those readings with a clear idea of how to use it to rid myself of the above. Then I saw Walter's comment in the link above. Aha -- you can just import header files in D code! Walter's comment made two things clear -- how to use ImportC in my case and that the documentation needs to be corrected and improved with an example of importing a C header file. Importing header files so you can directly use C libraries is a major reason why ImportC is an important addition to D and it should be crystal clear in the documentation how to do it.

This shows that we need HOWTO or tutorial with explanation of possible usage and how to deal with possible problems.

On 11/9/22 07:00, Don Allen wrote: > This is the standard pre-ImportC approach. Messy and ugly, but it works. Yes, there are issues with non-standard solutions: People have to repeat each other, don't know about existing solutions, there is a different kind of learning curve, etc. For example, there is https://gtkd.org/ and I had watched Gerald Nunn's presentation: https://dconf.org/2017/talks/nunn.html but I can't be sure without researching even whether gtkd is the same thing that was covered in that presentation. Then there are dpp, DStep, etc. (which I "remembered" their names only by visiting the ImportC page). It is similar with unit testing: I can't even remember what framework I had settled on during my C++ days but I will never forget the keyword 'unittest'. So, yes, I am convinced that a native solution enables so much for so many people. > The documentation does not say that, unless I've missed > something. Yes, other parts of the spec can be improved but the "spec" for this young feature is here: https://dlang.org/spec/importc.html > This all took less than an hour. I've > done some cursory testing and it seems to work properly. I was quite > amazed at how easy this was. Thank you for reporting your experince. I am guessing all this happened after the DConf Online submission deadline so we will see you explain it at the next in-person DConf. :) Ali

On 11/9/2022 10:54 AM, Don Allen wrote: > Not too surprisingly, given how new ImportC is, more testing *has* resulted in problems. I'll have more to say if/when I better understand the issue(s). Please post any problems to bugzilla, and tag them with ImportC. Thanks!

Forums