4 ms·

“If you’re arguing, you’re losing.”. That is a quick way to stop any discussion. The reason I am not using C++ is because C already does everything I need: - E

“If you’re arguing, you’re losing.”. That is a quick way to stop any discussion. The reason I am not using C++ is because C already does everything I need: - Easier to write code generators for: I use libclang to read in annotations that will generate new code according to where the annotations are being used. If I have to take care of every edge case and new features added to the latest C++ standard it would make the code generator more complex. - Using plain old data structures: My code generator generates new code to be able to work with the plain old data structures which data can be interleaved or non-interleaved using data-oriented design. Classes will not add that much value. - C compilers are easier to write: I integrated the tiny C compiler inside my program to be able to compile C code on demand. The C code can then use the code I've already written. - No name mangling by default: I dynamically load a lot of plugins and do not want to bother with binary incompatibilities all the time (if compiled by different compilers like the tiny C compiler for ex.). - I mostly use libraries written in C - Low-level access If I need concepts or meta-programming etc. I can already use Nim or write my own code generator, else I would rather choose something different than C++. To be more on-topic. Confirmation bias. On The Internet you can find confirmation of something being true about almost every topic. Whatever people believe is the truth, it will not change the reality. Which programming languages are better is a very difficult thing to measure because there are many factors to consider. Being used to a certain programming language can be a good reason not to change. https://en.wikipedia.org/wiki/Confirmation_bias https://en.wikipedia.org/wiki/Confirmation_bias Update: added some explanations, and more on-topic

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 ago
  I 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).

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 ago
I 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).