 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / November 2006unmanaged pointer in managed c++
Hi, i'm new to this stuff so please excuse my lack of understanding!!! I've got an unmanaged class called Category and a coresponding managed class, also called Category (shown at the end of this message)... I can create and manipulate the class successfully in c#, but it crashes and i get the following error message when "delete m_pCategory;" is called in the Finalize() : Debug Assertion Failed! File:dbgdel.cpp Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) Any ideas what could be causing this??? Any help is greatly appreciated: /// <summary>Constructor</summary> Category::Category(Utils::Category* pCategory) : m_pCategory(pCategory) { } /// <summary>Destructor.</summary> Category::~Category() { delete m_pCategory; m_pCategory = NULL; } /// <summary>Finalize.</summary> Category::!Category() { delete m_pCategory; m_pCategory = NULL; > Hi, i'm new to this stuff so please excuse my lack of understanding!!! > I've got an unmanaged class called Category and a coresponding managed [quoted text clipped - 30 lines] > delete m_pCategory; > m_pCategory = NULL; All the examples I've seen using a different class name for the managed and unmanaged classes. I guess if they are in different name spaces, then you can disambiguate them easily enough, but it might be better to use different class names while you are learning. What I'd like to see is how you declared m_pCategory. I think this should be declared as a pointer to the unmanaged type, but if both classes are named Category, then it may be thinking that in the context of usage, you are referring to the managed Class. If that is the case, then I don't think you can perform delete on m_pCategory because it would be a amanged type. I may be very wrong, as I am just learning, but I would strongly suggest you try using different names for the classes as a test, to ensure that m_pCatogory is declared as an UnmanagedCategory, since it points to an unmanaged type. >> Hi, i'm new to this stuff so please excuse my lack of understanding!!! >> I've got an unmanaged class called Category and a coresponding managed [quoted text clipped - 45 lines] > classes as a test, to ensure that m_pCatogory is declared as an > UnmanagedCategory, since it points to an unmanaged type. True, but that would show up as a compile-time error. What I want to see is the call to Category::Category(Utils::Category*). If the argument is coming from anything but the return value of scalar new Utils::Category(...) you will see this type of misbehavior when you delete. My guess is the Utils::Category was created on the stack, inside another object, or using the array new operator. > True, but that would show up as a compile-time error. > [quoted text clipped - 3 lines] > My guess is the Utils::Category was created on the stack, inside another > object, or using the array new operator. Yes, the Utils::Category was created inside the constructor of another object called RDConfig, as shown below: RDConfig::RDConfig() : Category(new RD::Utils::RDConfig()) { m_pConfig = reinterpret_cast<RD::Utils::RDConfig*>(m_pCategory); } And in the unmanaged side of things, RDConfig is derived from Category... Any ideas??? >> True, but that would show up as a compile-time error. >> [quoted text clipped - 17 lines] > And in the unmanaged side of things, RDConfig is derived from > Category... Any ideas??? The assertion you mention occurs when an object is deleted twice. Given your design, chances are good that this is the case: * the object is created and deleted in unrelated places: it is created in the RDConfig constructor and deleted in the Utils::Config destructor * further unrelated pointers (m_pConfig) refer to the object I would set a breakpoint in the Category destructor and see when it is called. Then I would run without the breakpoint and inspect the callstack where the assertion fails. Chances are good that this gives you the locations of both deletions of the category object. Furthermore, I would change the design, so that the object is created and destroyed in one class. Marcus >> True, but that would show up as a compile-time error. >> [quoted text clipped - 17 lines] > And in the unmanaged side of things, RDConfig is derived from > Category... Any ideas??? Since it's a base class, it's constructed in the same fashion as RDConfig... so where is RDConfig constructed? Also you are deleting virtually, so you should make sure Utils::Category has a virtual destructor. Thanks a million Ben! My destructor wasn't virtual, now everything seems to be running smoothly! Have a great weekend... Thanks again Actually, thanks everybody for all your help
Free MagazinesGet 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 ...
|
Reply to this Message
|
 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.