How bad are multiple @cImport's

Hey @Loaf, welcome aboard Ziggit.

You are correct about the multiple-namespace issue.

The problem that people get themselves into is a situation like the following:

  +-----------.h-----------+
  |                        |
a.zig                    b.zig
  |                        |
  +------communicates------+
               |
               v
             Result

The issue here is that both a.zig and b.zig have their own header imports so they may have common declarations (like typedef’s) and you might think that they should be able to communicate. Like if a function foo in a.zig returns a T that was imported from the header file and a function bar in b.zig takes the same T in defined in the same header file, you might assume they should be able to communicate. After all, it’s the same header, right?

Here, if a.zig and b.zig have their own cimports, those types will not be considered the same and they’ll each get their own declarations, etc.

Instead, if we make a common include between them and import that to both .zig files, we can now communicate.


The other situation you are referring to is having multiple cimports for different header files. Say a.zig takes foo.h and b.zig takes bar.h. If both of these do not expect to communicate on some common user-defined C type, there’s no issue here really. Each one is insular and thus it doesn’t really matter - no types to be confused between the two.

Hope that helps.

3 Likes