It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
C/C++ has text-based inclusion, which is just not a sane form of importing stuff from other modules. This is why we can get crazy stuff like broken partial builds. Most other languages are saner to build and some even come with tailor-made build tools.
Using a saner tool than plain make for C/C++ is worth it every time in my book.
make can still be very useful for other stuff, though.
That is great for simple projects, but a real toolchain for c++ needs to handle complex real world code. That means you have a mix of FORTRAN, ada, c, rust, some custom internal corporate language, and so on all mixed with the C++. If your build system cannot handle that mess i'm not interested
You don't have to; C++ can work just fine with object files using C name mangling, so it's no problem to mix C and C++ in the same project even if the source files are compiled with different compilers.
Whether they are used as a justification to use C/C++ for new projects (which isn't an argument I've seen), it's still better to have some solid tools available to find security issues in the existing C/C++ code that's already out there.
I work on a decade-old codebase where we freely mix C++, Obj-C++ and Obj-C as it makes sense and I can't say it's ever been an issue. Obj-C++ has some oddities, but on the whole mixing obj-c and c++ features works totally fine and I've never encountered a reason to want to separate them.
Mixing high level C++ stdlib classes with low level C APIs is often not exactly trivial, for instance most C++ containers expect that their items are RAII compatibel, and the resulting memory corruption errors will be harder to debug than plain old C code because the shit hits the fan deep inside some completely unreadable C++ stdlib implementation code.
I'm not talking about prebuilt binary libraries, much less DLLs. I'm comparing it to just dropping an .h and a .cpp file directly into your project. This one requires dropping an .h file, and then either adding a .cpp file (which you have to write manually, even if it's just one line of code), or adding an implementation #include to one of the existing .cpp files.
I guess my point is that I just don't see the benefit of concatenation here.
Part of the issue with doing that is that by compiling as C++ the symbols get mangled in a different manner and can lead to areas where you have to compile nearly everything as C++. Or you have to make sure that everything that you might want to face the outside world is marked with extern "C" {}.
They are hacks that paper over the lack of good package management. Plus they are too much extra work, and OS-specific. No build system integrates with them as far as I know.
I think what people want is something like go, where you add a single line to your code and it magically downloads and compiles the referenced library. C++ doesn't have anything like that (and I doubt it ever will to be honest).
> Even C++ which is a bit safer in practice is harder to link.
Not to go down the C++ evangelist route, but if you want to write libraries in C++ to use with other high level languages, you can wrap the headers in extern "C", and still write C++ as normal in your own code.
reply