Conversation

Replying to
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.
3
3
Replying to and
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
3
Replying to and
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
Replying to and
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
Replying to and
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
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
Show replies