4 ms·

> but for most user-facing applications that tend to have complex object lifetimes, I just can't see why you'd want to deal with RIAA when modern GC's are so da

> but for most user-facing applications that tend to have complex object lifetimes, I just can't see why you'd want to deal with RIAA when modern GC's are so darn good. My day job is ~half c++ and ~half c#, and I couldn't possibly disagree more. The first problem is IDisposable and event handlers. Because c# doesn't have anything like weak pointers, event handlers require that you manually dispose of half your objects. In c, there's a simple rule: you always dispose of your objects. In c++, there's a simple rule: the destructor of your data structure/smart pointer always disposes of your objects. In c#, the rule isn't simple. Half the time, you have nontrivial destructor doing nontrivial things, the other half the time you can leave it up to the GC. But it isn't necessarily immediately clear which is which. The second is `using`. Again, you must necessarily mix the semantics of non-deterministic GC cleanup and deterministic RAII cleanup. Which is worse than having a simple rule that always works.

Const-me 7y ago
> c# doesn't have anything like weak pointers https://docs.microsoft.com/en-us/dotnet/api/system.weakreference https://docs.microsoft.com/en-us/dotnet/api/system.weakrefer... https://docs.microsoft.com/en-us/dotnet/api/system.weakreference-1 https://docs.microsoft.com/en-us/dotnet/api/system.weakrefer... https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.c... > event handlers require that you manually dispose of half your objects. You probably have software design issue on your day job. C# events can be great, but they're not a silver bullet. For loosely coupled application wide events, event aggregator pattern works better, see IEventAggregator from Caliburn.Micro for an example. If the two sides of the event handlers need strong coupling for a good reason, an interface or abstract class for the consumer works better, see ExpressionVisitor from System.Linq.Expressions for an example.
- pjmlp 7y ago
  You forgot to add safe handles as well. https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.i... This and the the thread of the other day regarding having to use C for what C# is capable of, apparently many don't look on their toolboxes.

Const-me 7y ago

> c# doesn't have anything like weak pointers https://docs.microsoft.com/en-us/dotnet/api/system.weakreference https://docs.microsoft.com/en-us/dotnet/api/system.weakrefer... https://docs.microsoft.com/en-us/dotnet/api/system.weakreference-1 https://docs.microsoft.com/en-us/dotnet/api/system.weakrefer... https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.c... > event handlers require that you manually dispose of half your objects. You probably have software design issue on your day job. C# events can be great, but they're not a silver bullet. For loosely coupled application wide events, event aggregator pattern works better, see IEventAggregator from Caliburn.Micro for an example. If the two sides of the event handlers need strong coupling for a good reason, an interface or abstract class for the consumer works better, see ExpressionVisitor from System.Linq.Expressions for an example.

pjmlp 7y ago
You forgot to add safe handles as well. https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandle?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.i... This and the the thread of the other day regarding having to use C for what C# is capable of, apparently many don't look on their toolboxes.