News for hackers. Stuff that matters.
Re:Modern garbage collection: Part 2 by nwallin on Saturday December 14, 2019 @10:41PM (#21794302)
In my experience it's been the opposite.

We work on a dual C++/C# codebase. Something like 3/4 C++ and 1/4 C#. Basically all of the memory lifetime errors happen in C# land. I do not recall a memory lifetime error _ever_ hitting master in C++, but we have one bug against _prod_ right now and two bugs against master right now, as we speak in C#.

Dealing with lifetimes in C++ is easy, dealing with it in C# is a nightmare. Maybe it's easier in Java or Go, I don't know, I've only dealt with Java in school and never coded in anger in Go.

Re:Modern garbage collection: Part 2 by LessDmesg on Sunday December 15, 2019 @03:30AM (#21795155)
Interesting. Could you give an example of such a memory lifetime bug in C# and why C++ is impervious to it?
Re:Modern garbage collection: Part 2 by nwallin on Monday December 16, 2019 @10:18PM (#21810206)
async factory methods for stuff the API requires me to keep around, but the same API requires my objects to be constructed synchronously. (This includes stuff in .NET) C++ doesn't have async as a language construct. (yet. I dread the day.)

IDispose. We have an ecosystem where a nonnegligible number of in flight objects need to manually be disposed of. In C++, RAII takes care of this for us.

Un listening to events. Needs to happen manually in the standard .NET listeners. C++ solves this with weak_ptr. C# could solve this with a better standard library, but we have .NET.

Honorable mention (not lifetime, but the deadlock quagmire that is C# and its half async half synchronous standard library) is WritableBitmap, which is impossible to use correctly, and has not been deprecated or had a safe replacement offered.

C++ surprises me in ways I expect to be surprised. C# surprises me in ways that leaves me confused and perplexed.