3 ms·
You're using C in a cool way, but: 1) By using libclang to parse your own annotations you're kind of using your own fork of C language, not the standard one. Y
by self_awareness 9y ago
You're using C in a cool way, but:
1) By using libclang to parse your own annotations you're kind of using your own fork of C language, not the standard one. You can't really bring your annotation parsing engine to some company to work on an existing C project,
2) C++ also uses plain old data structures, using 'class' does not magically introduce any overhead in structures, unless you start using virtual functions, but nothing forces you to do it,
3) I think that by stripping name mangling you actually increase binary incompatibility, because without mangling you can't know what ABI was the function compiled against. Which compiler was it? What are the arguments? Is it MS ABI or UNIX ABI? Nobody knows for sure even if it seems to work correctly for some set of arguments. Disabling mangling sure is convinient at the beginning, but brings problems and incompatibilities at later stage.
4) Given that Windows or macOS kernel drivers are written in C++ (more or less), low level access is possible in C++ as well.
- deorder 9y agoI am aware that all of this is possible in C++ as well and for many things C++ might be the better choice (more standardized compiler hints instead of using pragmas, generics and templates etc.). What I meant is that C++ does not add anything for me personally. POD-structures are all I need and the way I fetch/store the data may require the struct layout to be interleaved or non-interleaved (depending on the platform / architecture I am targeting for a specific build) requiring different code to be generated to access them. I do not need to disable name mangling or add 'extern "C"' everywhere (I still do in case the code will be used from C++) when I just use plain C. I like the many new features added to C++ like concepts, lambdas etc. but for these I prefer to use Nim (they just added complete concept support as well).