3 ms·

Because it is. MS's developer tools have gotten quite nice but the OS itself is a sprawling mess.

projektfu 6y ago
The examples in the docs were also usually the bare minimum to show that the function existed, and usually full of memory leaks and bad behavior. Guessing what errors might arise was always fun. And then, the OS started inserting proxies on your interfaces whenever it wanted without telling you it might happen. Fun times all around. Favorite “COM-ism”: IClassFactory, the basic interface to a class. Why not call it IClass? Or IFactory since a class is essentially a Factory pattern? IClassFactory makes it sound like a Factory for Classes, not objects.
- commandlinefan 6y ago
  > full of memory leaks With an interface like AddRef/Release, they all but guarantee memory leaks.
  - pjmlp 6y ago
    If using bare bones C, yes definitely. Developers that know what they are doing would use a C++ library with support for COM smart pointers, .NET or Delphi.
    - recursive 6y ago
      Using COM from .net absolutely does not prevent leaks. I still don't really understand COM to this day, but I vividly recall spending significant effort and ultimately failing to do Office interop without leaking.
      - asveikau 6y ago
        My experience using COM with .net is that the GC does not get the hint that there is significant memory that will be released when it drops the COM wrapper object, so a "big" COM object or even many ones will not make the runtime start a collection and it ends up as a leak even though kicking the GC would probably do the right thing. So I would end up wrapping the objects in IDisposable and calling Marshal.ReleaseComObject on Dispose. Then COM objects were usually wrapped in using() to remain idiomatic for manual cleanup in c#. That was some years ago.
  - asveikau 6y ago
    If you put it in a C++ smart pointer it winds up pretty similar to ARC. (Yes, I have heard the compiler person's explanation that an ARC-type solution can generate fewer reference count modifications than a c++ smart pointer.)

The examples in the docs were also usually the bare minimum to show that the function existed, and usually full of memory leaks and bad behavior. Guessing what errors might arise was always fun. And then, the OS started inserting proxies on your interfaces whenever it wanted without telling you it might happen. Fun times all around. Favorite “COM-ism”: IClassFactory, the basic interface to a class. Why not call it IClass? Or IFactory since a class is essentially a Factory pattern? IClassFactory makes it sound like a Factory for Classes, not objects.

commandlinefan 6y ago
> full of memory leaks With an interface like AddRef/Release, they all but guarantee memory leaks.
- pjmlp 6y ago
  If using bare bones C, yes definitely. Developers that know what they are doing would use a C++ library with support for COM smart pointers, .NET or Delphi.
  - recursive 6y ago
    Using COM from .net absolutely does not prevent leaks. I still don't really understand COM to this day, but I vividly recall spending significant effort and ultimately failing to do Office interop without leaking.
    - asveikau 6y ago
      My experience using COM with .net is that the GC does not get the hint that there is significant memory that will be released when it drops the COM wrapper object, so a "big" COM object or even many ones will not make the runtime start a collection and it ends up as a leak even though kicking the GC would probably do the right thing. So I would end up wrapping the objects in IDisposable and calling Marshal.ReleaseComObject on Dispose. Then COM objects were usually wrapped in using() to remain idiomatic for manual cleanup in c#. That was some years ago.
- asveikau 6y ago
  If you put it in a C++ smart pointer it winds up pretty similar to ARC. (Yes, I have heard the compiler person's explanation that an ARC-type solution can generate fewer reference count modifications than a c++ smart pointer.)