So just link in the C .o file.
If there was something that you just couldn't easily do with FB code, then the idea of embedding inline C code would have merit, much like embedding ASM code has merit in both C and FB.
Furthermore embedding C code is not as trivial as you make out. For example you couldn't just do this easily without significant processing by the FB compiler (which would make it a C compiler as well as an FB compiler):
Code: Select all
x as long
y as long
declare somefunc() as MyType Ptr
dim b as MyType Ptr
b = somefunc()
printf("%d, %d\n",b->x, b->y);
Any C reference to FB symbols would have to be processed and converted because there are differences in how the variables are actually named and referred to in the emitted C code. Just examine the C output from FBC and you'll see what I mean.
Personally if you're going to go to the work of making FB be able to parse C code, I'd far rather have FBC natively be able to include C header files (complete with preprocessing) in FB programs. That would make it trivial to interact with any and all C libraries out there without having to translate the header files.