It is true that there is C code that is conforming C++ code. However I would say if you’re using a C compiler with with “extern C” in the headers for C++ linker compatibility (as this library does) then saying C++ is about as misleading as saying a Rust library is C++ as you can link to that too.
As far as compatibility and “history” the languages are different enough now. There are both: features in C that do not exist in C++, and code that is conforming C that would be UB in C++. Saying C/C++ (for real) is usually a dumb target when it’s better to pick one and settle with that.
If it’s C, just say so. Everyone knows what extern C is, you don’t need to confuse.
Something very close, but that's not what you would expect for something that markets itself as a C++ library IMHO. Especially in 2024, most people would hope (or assume) that "C++" means "C++ 11" at least.
Definitely doesn't count as _lying_, but still underwhelming.
Right, but C++ started as an extension of C and is mostly compatible and historically you could compile C with the C++ compiler. I don't think it's a good comparison.
> historically you could compile C with the C++ compiler.
not any C, only the C++-compatible subset.
int* foo = malloc(sizeof(int));
has never worked in C++ for instance while it's valid C. Code that worked is code that people actually did effort to express in a way compatible with a C++ compiler.
You must admit that C/Python doesn't quite have the same cachet as C/C++. C & C++ also share the same name, C++ was born as a derivative of C (with classes), they have the same syntax, logical constructs etc. Python is not even a systems language.