No, but a person who hasn't written C++ will write way more bugs, because so many of the stuff they learned in other languages creates extremely severe bugs in C++ rather than compiler errors. I can understand anyone who wants to avoid having to deal with those learning mistakes that every new C++ programmer has to go through.
In C++ code that looks right and clean to a non-C++ developer and that passes tests can still crash the entire program in production with no stack trace available. Or you can accidentally make copies of a big collection every function call (since C++ is pass by copy value by default even for large collections) in a hot path which would also bring down production, or massively inflate your bills if you dynamically scale up.
The same doesn't apply to most other languages, there experience transfers much better and its unlikely for experienced programmers to add novice bugs in those even if he has never programmed in it before.
C++ experience is like bash or Perl experience. You can write something, often not even that bad, but you will be much slower and there will be a lot of cliffs from which you will fall.
It is not to boast or sanctify the language. After 15 years of commercial experience with it I just hate it and feel like it is a lot of useless knowledge, which I regret. It can be useful and there are always trade-offs, but I still hate it.
Nah. Many people who have been writing C++ poorly for decades never learn to do it better. This is less about "even people who are great are bad" and more about "no amount of experience guarantees that you get great". There are plenty of ways to write the language that aren't as error-prone, and most development of new features in the language since at least 2011 have been creating new ways to do that more. The "problem" is that they value backwards-compatibility, and most pedagogy for the language both in academia and industry is at best outdated and often just teaching bad ideas outright, often both, so while there are whole enormous and robust codebases out there that don't use them at all, the idioms that contain footguns still exist in the language and are valid code and some old dude who's been doing this for 30 years will still sit in a meeting and tell me that he's been writing pointer arithmetic in deep nested loops for 20 years and it should work fine after insisting on being in part of a review process that is for the most part not adding any new information halfway through a rewrite process to fix some show-stopper bugs in a legacy codebase, which ended up making said process about 10x more annoying and take at least twice as long
> some old dude who's been doing this for 30 years will still sit in a meeting and tell me that he's been writing pointer arithmetic in deep nested loops for 20 years and it should work fine
Pointer arithmetics in nested loops is just regular C code though, that is perfectly fine. The problem comes when you start to mix C++ datatypes and templates with pointer arithmetics, that is when the footguns becomes completely unmanageable.
However if your team doesn't have other people with experience writing such code then it is best to avoid it anyway, if you decided to not write C style code in C++ then he should respect that. But he is right that it is perfectly fine thing to do, writing C in C++ is basically just C with namespaces and scoping.
Sure, it's doable, but it was in this case the source of the issue, along with some obfuscation of where and when those particular sections of code were being executed through shenanigans with encapsulation and inheritance (I respect people who can manage their pointers well, but I genuinely dislike a lot of OO practices even aside from if they're done "well"). People write exceptional code in C despite and sometimes because of it not protecting you from writing it wrong. I respect the view that some people don't need their programming languages to protect them from these problems. In this case, it helped quite a lot, especially since the application was essentially reimplementing vector processing, getting the memory management wrong, and not doing anything to justify not taking advantage of the insane degree of optimization that's gone into std::vector
Nothing if you do it right. Indexing also goes wrong if you do it wrong. In both cases, they make sense as abstractions, but are less safe than certain other abstractions
I see lots of good code in the linux kernel that uses explicit indices and pointer arithmetic. It's written by people who know what they're doing with it, and perhaps more importantly, have hundreds of maintainers gating updates directly with review and thousands of open-source enthusiasts who might notice a problem
However, many modern languages, including C++, can do a lot of the things you might do in this explicit way in other ways that are considerably harder to screw up, and often drastically more efficient to boot, which was the case here. I think the guy I was interacting with wasn't even the one who wrote the code, he just had the vague sense that really good coders could write code this way, so it must be a good way to go about writing code. My point isn't that it's inherently bad or going to fail necessarily, just that it's the kind of pattern people mean when they complain about older languages without as many guardrails. This particular code was causing a memory leak that eventually crashed the device in some but not all of the contexts that called it, not because it was pointer arithmetic, but it had stayed broken and gotten more broken because the ways in which it was done wrong were harder to notice and suss out in that form than what I eventually worked it into, and the way that I did that used newer idioms (mostly involving lambda capture, moving some of the implicit polymorphism accomplished by casting pointers into explicit templated functions, and moving things into vectors to isolate where things were going off the ends of arrays, nothing super fancy, but newer than this guy who hadn't worked in C++ in a decade had seen), and we were all stressed out but it was definitely annoying that I was getting all these notes on interim commits that were basically a guy who was not on that project and did not understand the code trying to flex seniority on me by insisting that doing stuff in a way he didn't understand was wrong and bad. To his credit, after some of the stress had passed he did try to learn some of the functional-first kit of idioms I had used to fix the issue (once he saw that this indeed was what had happened), but it still left a sour taste in my mouth. I really dislike most interactions that are deeply concerned with status
I've written a lot of C/C++ and I've seen the cases where it makes sense, sometimes even is better to use the kinds of patterns that motivated language design choices like explicit pointers and casting and calling new all the time to allocate class instances, where those things still are necessary or efficient or even just make sense. But also, they are the kinds of things people complain about when they say that the language lets you make a lot of mistakes many other languages, especially newer ones, don't. I often write in subsets of C++ that have this property, and converting code I'm not ultra familiar with to equivalent functionality using different idioms just to see is often a productive way of finding and eliminating difficult bugs. This doesn't mean no one can or is writing good nested loops with pointer arithmetic driving the iteration, but it's a place to look for errors because it's harder to be good at that than it is to write a range-based for loop
C++ has all the footguns of C, but add in tons of implicit function calls that creates bugs for half of the things you'd think they can be used for, and because you don't see that implicit code it is really hard to debug why an implicit call was made or not made when you thought it would or wouldn't.
So no, C isn't even close to the danger of C++, in C every copy, every destructor, every alloc, is explicitly declared everywhere. Explicit is much safer than implicit, unless the implicit behavior is rock solid like in garbage collected languages, or very strict languages like Rust.
Agreed. Explicit is only better than implicit when you have a mechanism that can reliably identify instances where you forgot to do something.
Actually for resource management I'd go so far as to say that implicit is better than explicit in the vast majority of cases. Now if only the rules that determine what happens during initialization in C++ weren't so horribly convoluted.
The way I see it is that what most companies hiring c++ programmers really need are good systems programmers. However, being an expert in advanced and/or esoteric features of the shitshow that is the C++ language is neither necessary nor sufficient to be a good systems programmer.
