Do you know when your destructors run? Part 1.

re: Do you know when your destructors run? Part 1.

Stephane Rodriguez — Thu, 20 May 2004 14:37:00 GMT

If the code is made full of implicit construction/destruction that will, because it's unmanaged code, cause spectacular GPFs for any reason, then I am not sure there is any improvement here. I wonder if this isn't a pledge for managed code.

Also wonder of next part will cover smart pointers used in class members. Plenty of funny things here.

Does anyone if a third party ever came with a COM component manager that would insulate developers from these things without being frightened of GPFs. I know that you can switch to managed code today, yet given that the ROT is of no help without explicit monikers - something that not many people seem to use in the real world - is there any tool to diagnose internal COM life cycle issues?

re: Do you know when your destructors run? Part 1.

Jack Mathews — Thu, 20 May 2004 14:49:00 GMT

While managed code would stop GPF's from happening, there are still PLENTY of logic problems that can and will happen from destruction order issues. This just happens to be one that crashes, but in managed code or not, you can make objects go to an invalid state and then try to use them to make bad things happen.

re: Do you know when your destructors run? Part 1.

Paul Bartlett — Thu, 20 May 2004 14:52:00 GMT

Slight error (I think). Shouldn't it be p.Release() and p.CoCreateInstance(...). The former is a "well known" gotcha with ATL smart pointers.

re: Do you know when your destructors run? Part 1.

Raymond Chen — Thu, 20 May 2004 15:28:00 GMT

Oops, thanks Paul. I guess this reveals that I don't use ATL smart pointers much...

re: Do you know when your destructors run? Part 1.

Mike Dunn — Thu, 20 May 2004 17:40:00 GMT

p->Release() actually won't compile. ATL guards against that incorrect usage by having operator-> return a _NoAddRefReleaseOnCComPtr*. The trick is that that class has the AddRef() and Release() methods private, making them inaccessible by the code trying to do p->Release().

re: Do you know when your destructors run? Part 1.

Catatonic — Thu, 20 May 2004 21:26:00 GMT

After I read Larry Osterman's post a few weeks ago, I created a class that's almost identical to your CCoInitialize example. To me it feels like the natural solution.

re: Do you know when your destructors run? Part 1.

BeenThere — Fri, 21 May 2004 01:01:00 GMT

I know this is just an example, but if CoInit was occasionally failing in my code I would want to know why. Does some unrelated code sometimes set the thread up with a different concurrency model? An assert might be nice. Also, shouldn't you be using CoInitializeEx?

re: Do you know when your destructors run? Part 1.

Raymond Chen — Fri, 21 May 2004 01:09:00 GMT

CoInitialize(NULL) is the same as CoInitializeEx(NULL, COINIT_APARTMENTTHREADED).

re: Do you know when your destructors run? Part 1.

BeenThere — Fri, 21 May 2004 01:20:00 GMT

MSDN says "Applications developed today should call CoInitializeEx rather than CoInitialize," so that is what I always use.

Do you know when your destructors run? Part 2.

The Old New Thing — Fri, 21 May 2004 17:02:00 GMT

Sometimes they don't run at all.