Manged pointer to local object
-
Hello! When I have a managed pointer to a local object t that goes out of scope, the destructor of t is called. Does pt still point to valid memory (and I can mark t as invalid), or is there any other way to find out if the object pointed to by pt was destroyed?
Test^ pt;
{
Test t;
pt = %t;
}pt->...
Thank you! Alex
-
Hello! When I have a managed pointer to a local object t that goes out of scope, the destructor of t is called. Does pt still point to valid memory (and I can mark t as invalid), or is there any other way to find out if the object pointed to by pt was destroyed?
Test^ pt;
{
Test t;
pt = %t;
}pt->...
Thank you! Alex
LionAM wrote:
is there any other way to find out if the object pointed to by pt was destroyed?
pt is still valid in your code. There's no "pointers" here - these are managed references. You have created a new reference to t by assigning a tracking reference of t to pt. As long as pt stays in scope it is a valid Test reference. You can assign nullptr to references...
Test^ pt;
{
Test t;
pt = %t;
}
pt = nullptr;
if (nullptr != pt)
{
pt->...
}*edit* I played around with this and with stack based semantics the destructor is still called as you stated. This behavior makes code like your example dangerous. I'd prefer using all reference semantics if I was going to obtain additional references, something like
Test^ pt;
{
Test ^t = gcnew Test();
pt = t;
}
delete pt; // destructor called here!
pt = nullptr;That seems clearer to me *shrug*
MarkMark Salsbery Microsoft MVP - Visual C++ :java:
modified on Monday, August 18, 2008 3:17 PM
-
LionAM wrote:
is there any other way to find out if the object pointed to by pt was destroyed?
pt is still valid in your code. There's no "pointers" here - these are managed references. You have created a new reference to t by assigning a tracking reference of t to pt. As long as pt stays in scope it is a valid Test reference. You can assign nullptr to references...
Test^ pt;
{
Test t;
pt = %t;
}
pt = nullptr;
if (nullptr != pt)
{
pt->...
}*edit* I played around with this and with stack based semantics the destructor is still called as you stated. This behavior makes code like your example dangerous. I'd prefer using all reference semantics if I was going to obtain additional references, something like
Test^ pt;
{
Test ^t = gcnew Test();
pt = t;
}
delete pt; // destructor called here!
pt = nullptr;That seems clearer to me *shrug*
MarkMark Salsbery Microsoft MVP - Visual C++ :java:
modified on Monday, August 18, 2008 3:17 PM
-
Thank you. I see that the local (ref) object is also on the managed heap - the only difference is that the destructor is called. In my case, I need the local object because it is a lock (which has to be destroyed when leaving scope). Alex
LionAM wrote:
In my case, I need the local object because it is a lock (which has to be destroyed when leaving scope).
Makes sense. Just for reference, there's other ways to get the destructor called:
(from Destructors and Finalizers in Visual C++[^]):
Code authored in Visual C++ and compiled with /clr will run a type's destructor for the following reasons:
\* If an object created using stack semantics goes out of scope. \* If an exception is thrown during the object's construction. \* If the object is a member in an object whose destructor is running. \* If you call the delete Operator (C++) on a handle (^ (Handle to Object on Managed Heap)). \* If you explicitly call the destructor.
If your type is being consumed by a client authored in another language, the destructor will be called when:
\* A call to Dispose. \* Calling Dispose(void) on the type. \* If the type goes out of scope in a C# using statement.
Regardless, having a second reference outside the scope is a bad idea and shouldn't be necessary :) Cheers, Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: