On the contrary, that has been the argument from the C side since the comp.lang.c days trying to prove a point that C is still relevant without understanding that was C++'s Trojan horse.
Also just because it looks like C the semantics aren't the same, e.g. implicit conversions from void* aren't allowed in C++ compilers, ?: has a different precedence and a couple of other differences, this still in C89, let alone with everything that came afterwards.
These are pretty minor things that don't matter semantically or with regards to safety. For example I never knew that there was a difference in the precedence of the ?: ternary operator (which I don't use anyway), but I'd wager that it's more the byproduct of different language formalization methods, and not an intended change. There surely can't be a significant difference because it would hinder the Trojan effect.
void* not implicitly casting to their assigned value in C++ is an annoyance to me at best. I don't see any advantage at all there.
Things that matter are for example that C++ has vectors or other container types with the possibility to enable bounds checking with a compile flag. Well, you'd think they matter, because it is a security improvement at first sight, and I certainly thought so. I do now think that it makes programs significantly harder to maintain, to the point where superficial advantages cancel out or turn negative.
If that effect wasn't real at least to some extent, I wonder why do I see SO MANY function signatures in C++ projects where functions are passed in classic pointer + length style.
Furthermore tools like valgrind can be helpful in a way that gives some of the benefits of language-level methods for bounds-checking.
Why you see them? Because developers should know better, but there is a community that keeps writing C style code in C++, unfortunately, as their teachers are stuck in the 90's.
Oh my, another day, another random unrelated link fest. I do happen to have watched that talk, and I'm not sure what point you want to make by linking to it. That talk is someone else's opinion how to get students to write some C++ that compiles - students with no prior understanding of C++ or of programming. Students that do not aspire to be great programmers or even to understand a little bit of what's happening here. That will not be able to help themselves when there's a 200-line error spewn from templated containers for example. That don't even want to understand (or have trouble understanding) the concept pointers.
It's NOT a talk suggesting that C is bad or that the use of it is bad (despite the title).
It's a talk that suggests that C++ needn't be hard. If we were about actually understanding the language and making significant use of its features, Bjarne Stroustroup himself begs to disagree with the idea that C++ is a language that an individual can fully understand.
It's a talk suggesting how to approach teaching when the goal is to get quick (and surely limited) results instead of understanding.
But that's totally uninteresting to me. If it's interesting to you, we should end doing more comments, and I should try not to be annoyed when I read your evangelism and your ton of comments where you often hop around and quickly change topic when someone disagrees, and where you instead throw more links to pages that may have a title that suits your agenda, but that are often low on content or dead-in-the-water stuff, or that are completely unrelated to the discussion.
> Things that matter are for example that C++ has vectors or other container types with the possibility to enable bounds checking with a compile flag.
As I mentioned above, templated containers is the one significant C++ feature that GCC uses. So maybe you now agree that it's not just C compiled as C++ after all?
Well I was never going into a "technically" argument, I thought that was pretty clear from the start. I had already knewn that those containers are used there in some places (although I didn't find any when I quickly skimmed the codebase 2 days ago). So let's just say "yes technically I agree" and maybe I won't seem as a totally boneheaded evangelist.
My actual intention and the reason for my comments was to put things into relation. Compared to what you want to argue about here, pjmlp has a totally different idea of how things are or should be, and which I think is rose tinted and skewed.
Using a templated container once maybe every few dozen or hundred lines is not a justification for unfounded and unbalanced hating, and it is no indication for taking this codebase as an argument that C is so bad that they couldn't deal with it anymore, so they had to switch to C++ which solved all their alleged problems. That's just not the way it is.
Not taking from that technical point of agreement, and as an aside because I can't resist, I personally prefer to just use stay with C completely/"technically", and I believe I get better results by improving the architecture of my projects to work around C's "shortcoming" of not having templated containers. One can even make a point that just templated dynamic vectors are easily available in C since C does have polymorphism for arrays, supported by its pointer syntax, and using valgrind and the occasional assert() you can get lots of the same benefits in terms of security. The way I go about this achieves the same level of convenience, minus RAII (which I found to be problematic on larger scale. Templated containers and maps are nice though for short throw away code and temporary variables that never leave the function scope.)
I also actually make heavy use of a C99 feature that is still not in C++, which is designated initializers to make static arrays (often readonly data) to map from enums to additional data. I also found that I've wasted a lot of my time trying to build arbitrary "nice" things in C++ and always finding myself in a place some time later where I've totally locked myself in, so that's why I prefer just not to use a C++ compiler at all, even if there are some little nice-to-haves that you can get with it.
So there you go, my rant that is totally out of place here, why I don't think C++ is a better choice even if used very lightly.
Also just because it looks like C the semantics aren't the same, e.g. implicit conversions from void* aren't allowed in C++ compilers, ?: has a different precedence and a couple of other differences, this still in C89, let alone with everything that came afterwards.