Destructor: not gauranteed to be called?

I'm programming in VS C++.NET 2005 using cli:/pure syntax. In my code I have
a class derived from Form that creates an instance of one of my custom
classes via gcnew and stores the pointer in a member. However, I set a
breakpoint at the destructor of this instance's class and it was never
called!!! I can see how it might not get called at a deterministic time. But
NEVER?

So, I guess I need to know the rules about destructors. I would have thought
any language derived from C++ would always guarantee the destructor of an
instance of a class be called at some time, especially if created via
[gc]new and stored as a pointer.

Yes, I think I can deterministically destruct it via 'delete' and setting to
nullptr. But the point still kinda freaks me that the destructor is no
longer gauranteed to EVER be called. I feel like I should be worried since
it is sometimes important to do other things besided freeing up memory in a
destructor. In my case I discovered it becuase I'm communicating through a
serial port which I change the baud rate from the current speed, but then
changed it back in the destructor - only to find out the destructor was
NEVER called! Hence, the port died, and MY program wouldn't work on
subsequent runs since it assumed the port had been returned to the same baud
(and hence couldn't communicate with it anymore).

So, again, why is the destructor no longer gauranteed to be called, and what
are these new rules? Or am I being ignorant, and C++ never made such
assurances. Inquiring minds want to know! : )

[==P==]


.

Relevant Pages

  • Re: is such exception handling approach good?
    ... No exception from this rule that I know of (no pun ... For the object pointed by smart pointer, ... Free that resource in the destructor. ... For resources other than the heap memory, you would use other classes to ...
    (microsoft.public.vc.language)
  • Re: Returning an unknown number of types/values
    ... >> destructor is empty the Base destructor will still clear up the memory ... This array was allocated to the unsigned char pointerin the Base class's ... The useful thing about this pointer ... THe probelm appears when you try to overload the second subscript operator ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Destructor: not gauranteed to be called?
    ... > my custom classes via gcnew and stores the pointer in a member. ... I set a breakpoint at the destructor of this instance's ... > the port died, and MY program wouldn't work on subsequent runs since ... They're not new rules - it's the nature of objects on the heap. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: reference to pointer of derived class
    ... > of a class in which I have a pointer to a pure virtual base class ... Garage(): pCar ... if the Car class has a virtual destructor. ...
    (comp.lang.cpp)
  • Re: STL vector<float> crash
    ... Which is when the destructor is called. ... Iterators aren't unsafe, but they aren't guaranteed to be pointer ... I can see where using the feof() return to ...
    (comp.lang.cpp)
Loading