4 ms·
You don't need multiple module instances, the modules just need access to details about the opaque type or private portions of a type. If you've ever seen this
by Jtsummers 4y ago
You don't need multiple module instances, the modules just need access to details about the opaque type or private portions of a type. If you've ever seen this in a C header:
struct foo;
That's an example of an opaque type. Put that in a header, and any function can make use of it in any other C file, they just can't access its innards (well, it's C so you actually can if you know how its contents are packed). Functions can accept them as parameters and return them knowing nothing but that opaque type and some additional function signatures like this (to do something useful with it):
struct foo make_foo(...); // or struct foo*
void print_foo(struct foo*); // or struct foo
So I can write something like this:
// main.c
#include "foo.h"
// other includes
void do_something(struct foo* f) {
// lots of code
print_foo(f);
}
int main(int argc, char* argv[]) {
struct foo f = make_foo(a_param);
do_something(&f);
return 0;
}
In a hypothetical C you could do something like this:
struct foo {
int a;
char b;
private;
};
That last bit indicating that there is something there, but not what it is. Then somewhere you'd have a fuller definition:
struct foo {
int a;
char b;
// private expanded
float c;
}
Which would be used by functions which are meant to actually operate on the rest of this structure. In this case, anything that knows of struct foo can directly access its "public" fields of a and b, but have no clue about the remaining fields.