Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / November 2005

Tip: Looking for answers? Try searching our database.

Unmanaged pointer cleanup in Managed class

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Maxwell - 20 Nov 2005 20:54 GMT
Hello,

Newbie question here for disposing of unmanaged resources in MC++.NET.
I have a managed VS.NET 2003 MC++ wrapper class that wraps a unmanaged
C++ dll. What I am trying to figure out is what is the "best practice"
for disposing of pointers to unmanaged classes that you have newed in
your constructor in MC++

For a better description of what is the standard affair I have tried
looking online at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/html/v
cmg_techniquesconstructorsdestructors.asp


but I would have to say its very lacking in detail or explanation. Does
anyone know of a better reference or can point me to for this?

My constructor looks something like this:

MClass::MClass()
{
    pUnmanagedClass_ = new UnmanagedLib::UClass(); //unmanaged heap
    pBridgeClass_ = new _UClassBridge(); //unmanaged heap

pUnmanagedClass_->RegisterUnmanagedCallBack(&(pBridgeClass_->UnmanagedBridgeCallback));
}

pUnanagedClass_ is a pointer to class in a unmanaged C++ DLL
pBridgeClass_ is a pointer to a __nogc class I created in MC++

Here is my destructor for this class:
MClass::~MClass()
{
     pUnmanagedClass_->UnRegisterCallbacks();
     pUnmanagedClass_->~UClass(); ///do I need this line

     delete pUnmanagedClass_; //because it was newed
     delete pBridgeClass_; //because it was newed
}

Since I newed the pointers I would guess that I would have to
explicitly call delete on them...is this the case? I also need to
ensure that destrutor gets called in the C++ DLL immediately
(pUnmanagedClass) so I added a line for this in the managed class
destructor...is this necessary or is it safe to assume it will get
called because the delete is called

Thanks
Lloyd Dupont - 21 Nov 2005 06:22 GMT
in your destructor/finalizer, don't call the ~destructor, call delete

> Hello,
>
[quoted text clipped - 42 lines]
>
> Thanks
JAL - 21 Nov 2005 07:54 GMT
Maxwell.. I am also new to C++/cli, but I notice that you are doing _two_
unmanaged allocations in the constructor. So if an exception is thrown
_after_ a first successful allocation, the object never exists and the
destructor is never called. So I think the unmanaged allocations in the
constructor need to be all or none, sort of like a transaction. If any part
of the construction fails, then things are rolled back to the "initial state"
and then rethrow the exception.

Hopefully, someone will chime in on this concern.

> Hello,
>
[quoted text clipped - 42 lines]
>
> Thanks
Carl Daniel [VC++ MVP] - 21 Nov 2005 14:44 GMT
> Hello,
>
[quoted text clipped - 41 lines]
> destructor...is this necessary or is it safe to assume it will get
> called because the delete is called

A couple points:

1. You don't need to explicitly call the destructor - the delete expression
will take care of that (in fact, you need to NOT call it, since otherwise
it'll be called twice and classes are not generally expected to handle
having their destructor run twice).

2. If the unmanaged classes are holding important resources (other than just
unmanaged heap), you should consider making your managed class IDisposable
and disposing of the unmanaged class in your IDisposable::Dispose.  The
~MClass "destructor" is the finalizer under MC++, and there's no guarantee
that a finalizer will ever run (since there's no guarantee that the GC will
ever run).

3. As another poster pointed out, you're doing multiple allocations in your
constructor with no try/catch protection.  You have potential resource leaks
if an exception is thrown in your constructor.  If you need to make it
bullet proof, I'd suggest picking up a copy of Herb Sutter's excellent book
"Exceptional C++" - about 1/2 of the book is about building exception
safety.

-cd
Maxwell - 21 Nov 2005 22:59 GMT
Wow that was great info, That definintely helped tons. Thanks for
pointing out the constructor issue. I was just assuming like in C# if
there was a exception in the constructor the class would not be created
and thus anything that was created in the constructor would be
destroyed automagically...guess not with MC++ because that was
unmanaged code which would make sense.

I'll definintely check out that book,

Thanks again for the replies

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.