Very simple question about gcnew in opreator overloading cases
-
Consider the unary operator overload as per the example in the Stephen G. Fraser book, "Pro Visual C++/CLI", p. 114: . . static OpClass^ operator -(const OpClass ^lhs) { OpClass^ ret == gcnew OpClass(); // gcnew invoked here. ret->i = -(lhs->i); return ret; } . . Let's say I have previously instantiated OpClass objects, fred and jane as follows: OpClass^ fred = gcnew OpClass(); fred->i = 15; OpClass^ jane = gcnew OpClass(); jane->i = 23; fred = -jane; ^ | +---- This causes the "ret" to be instantiated as a clsInt object and a copy ( by default memberwise copy? ) is assigned to fred^. Does ret's going out of scope at the close of the overloaded operator function call mark ret's space on the managed heap for garbage collection? And, if this were just traditional C++ would the ret's going out of scope mark it for "delete"ion or would I have to explicitly delete it (in my ancient Deitel & Deitel he doesn't delete it)? Thanks, in advance, Coop
Jeff Cooper
-
Consider the unary operator overload as per the example in the Stephen G. Fraser book, "Pro Visual C++/CLI", p. 114: . . static OpClass^ operator -(const OpClass ^lhs) { OpClass^ ret == gcnew OpClass(); // gcnew invoked here. ret->i = -(lhs->i); return ret; } . . Let's say I have previously instantiated OpClass objects, fred and jane as follows: OpClass^ fred = gcnew OpClass(); fred->i = 15; OpClass^ jane = gcnew OpClass(); jane->i = 23; fred = -jane; ^ | +---- This causes the "ret" to be instantiated as a clsInt object and a copy ( by default memberwise copy? ) is assigned to fred^. Does ret's going out of scope at the close of the overloaded operator function call mark ret's space on the managed heap for garbage collection? And, if this were just traditional C++ would the ret's going out of scope mark it for "delete"ion or would I have to explicitly delete it (in my ancient Deitel & Deitel he doesn't delete it)? Thanks, in advance, Coop
Jeff Cooper
aa1ww wrote:
Does ret's going out of scope at the close of the overloaded operator function
it doesn't go out of scope, it's returned
aa1ww wrote:
return ret; }
aa1ww wrote:
if this were just traditional C++ would the ret's going out of scope mark it for "delete"ion
Native C++ has no garbage collection so there is no marking of anything for deletion.
led mike
-
aa1ww wrote:
Does ret's going out of scope at the close of the overloaded operator function
it doesn't go out of scope, it's returned
aa1ww wrote:
return ret; }
aa1ww wrote:
if this were just traditional C++ would the ret's going out of scope mark it for "delete"ion
Native C++ has no garbage collection so there is no marking of anything for deletion.
led mike
Ok, bear with me here... fred is a handle to some resources gcnew'd in the instantiation of an OpClass object in the main program, right? Then, during the operator overloading function call, more resources were gcnew'd for the instantiation of OpClass (whose handle is ret). So ret is returned as a handle and fred (also an OpClass handle) is replaced, OK. But there are now two allocations of OpClass objects on the managed heap. perhaps the CLR notices that the previously allocated resources pointed to by fred before the overloading function call are now "orphaned" (when fred was replaced by ret) and can mark those resources for deletion? Thanks, Coop PS: Right, traditional C++ requires me to do explicit delete's on my allocated resources.
Jeff Cooper
-
Ok, bear with me here... fred is a handle to some resources gcnew'd in the instantiation of an OpClass object in the main program, right? Then, during the operator overloading function call, more resources were gcnew'd for the instantiation of OpClass (whose handle is ret). So ret is returned as a handle and fred (also an OpClass handle) is replaced, OK. But there are now two allocations of OpClass objects on the managed heap. perhaps the CLR notices that the previously allocated resources pointed to by fred before the overloading function call are now "orphaned" (when fred was replaced by ret) and can mark those resources for deletion? Thanks, Coop PS: Right, traditional C++ requires me to do explicit delete's on my allocated resources.
Jeff Cooper
aa1ww wrote:
perhaps the CLR notices that the previously allocated resources pointed to by fred before the overloading function call are now "orphaned" (when fred was replaced by ret) and can mark those resources for deletion?
It better since that is what a Garbage Collection systems primary purpose is. ;)
led mike