I find it to be the opposite. A lot of modern styles also encourage trying to be more efficient than the idiomatic C code with lots of dynamic allocations / copies. Most of the memory corruption bugs that I run into are in C++ despite there being about an equal amount of C code.
Conversation
There's a huge difference between the result of finding the bug too. I can usually fairly quickly come to an understanding of why the memory corruption bug occurs in C. On the other hand, it's often extremely difficult to unravel what goes wrong in many layers of C++ abstraction.
1
1
3
I've found bugs involving weird C++ object oriented reference counting bugs where I've spent ages trying to resolve the issues and have yet to actually figure them out. I'm not even talking about non-deterministic issues like races. I can reproduce these 100% of the time.
1
1
The same applies when reporting the bugs upstream. It takes them ages to figure out some of these issues too. It's a very weird feeling being able to reproduce a bug, knowing that it's a use-after-free but even a team of people struggle to figure out what exactly is going wrong.
1
1
I've always disliked class inheritance, but it's particularly scary in C++. Chromium and Android have these ridiculously complex interactions with it. There's this object oriented inheritance-based reference counting design in legacy Android code that I particularly despite....
1
1
1
Replying to
The sp<> templates? Those are gross, yeah… is there even any documentation for them?
1
Replying to
Yes, those horrible things. They're using C++14 for newer code with the standard library used much more, but std::shared_ptr + lightweight references including iterators (which is how it's actually used) can end up ridiculously hard to debug too. The problem can be so far away.
1
Once all kinds of fancy higher level inheritance and/or templates are involved, it gets so hard to unravel what is actually going on. The sp<...> reference counting is one of the most horrible things that I've ever had to deal with though. It makes me hate OOP and C++ so much.
1
There's documentation in android.googlesource.com/platform/syste. This change definitely helped, among others: android.googlesource.com/platform/syste (the commit date. It's still horrible. There's some ongoing work in master too: android.googlesource.com/platform/syste.
1
The gradual migration to modern C++ has also been painful. This is a very simple example of something that I see a lot (in a somewhat crazy component no longer used on A/B update devices): android.googlesource.com/platform/boota. I usually don't have time to report them let alone submit a patch.
1
1
Since these bugs are constantly being introduced and fixed. They do test with ASan, etc. but not absolutely everything. They would have seen this if they tested a legacy style system update with ASan, although maybe not since it immediately reboots after this code runs...
Simply having pervasive destructors mixed with unsafe lightweight references (which aren't just used for C compatibility like this) is a big issue. Modern C++ certainly uses lots of iterators (or range iterators, like Rust). I find this terrifying:
en.cppreference.com/w/cpp/string/b
1
2