<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div><span>Hi Duncan,</span></div><div><span><br></span></div><div><span>Thank you for all your reply.</span></div><div><span><br></span></div><div><span>If those really are both _var types, then I'm sure it is not actually<br clear="none">leaking.</span></div><div><span>>> I think I just have to trust you on this for now, even though VS is reporting it as a leak (yeah at times Microsoft's debugger reports the weirdest things unlike any other). Got to get some serious reading on the CORBA C++ mapping. Thank you and more power. Merry Christmas!</span></div><div><br></div><div>Regards,</div><div>Miff</div><span><div><br></div><div><br clear="none"></div></span><div class="yahoo_quoted" style="display: block;"> <br> <br> <div style="font-family: HelveticaNeue, Helvetica Neue,
Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> On Saturday, December 21, 2013 2:02 AM, Duncan Grisby <duncan@grisby.org> wrote:<br> </font> </div> <blockquote style="padding-left: 5px; margin-top: 5px; margin-left: 5px; border-left-color: rgb(16, 16, 255); border-left-width: 2px; border-left-style: solid;"> <div class="y_msg_container">On Wed, 2013-12-11 at 21:23 +0800, Mifflin Mabalot wrote:<br clear="none"><br clear="none">[...]<br clear="none">> module helloInterface {<br clear="none">> interface HelloInt {<br clear="none">> ::CORBA::WStringValue sayHello( ); <br clear="none">> };<br clear="none">> #pragma ID HelloInt "RMI:helloInterface.HelloInt:0000000000000000"<br clear="none">> };<br clear="none">> When I
compiled the IDL using omniidl, it produced the C++ header and<br clear="none">> implementation files containing this:<br clear="none">> CORBA::WStringValue* sayHello();<br clear="none">> At first I was not expecting (DID NOT NOTICE) sayHello() would return<br clear="none">> a pointer since the method signature in the IDL file does not (or<br clear="none">> maybe this is my fault for not reading the CORBA specs)...<br clear="none"><br clear="none">You really really have to understand the C++ mapping. It's horrible and<br clear="none">ugly, and has complex memory management rules. If you don't understand<br clear="none">the rules, you will get it wrong and your code will leak or, worse,<br clear="none">crash.<br clear="none"><br clear="none">> I just came to realize when I eventually noticed that the return value<br clear="none">> is a pointer...that sayHello() method was probably doing some internal<br
clear="none">> allocations. I am just wondering though, if you take a look at the<br clear="none">> declaration, I declared a _var object (m_HelloObj)..but the sayHello<br clear="none">> method (which is a member of the object m_HelloObj) isn't doing an<br clear="none">> automatic cleanup. In short, the _var object itself is automatically<br clear="none">> cleaning up it's allocations, but not allocations made by its member<br clear="none">> methods.<br clear="none"><br clear="none">Yes, the object reference _var type (HelloInt_var) looks after ownership<br clear="none">of the object reference. It does not have any bearing at all on<br clear="none">ownership of values returned from methods on the object.<br clear="none"><br clear="none">> For a first time orb user like me, these two would look the same:<br clear="none">> Version 1:<br clear="none">> CORBA::WStringValue_var l_sayHello =
TaskWork.m_HelloObj->sayHello();<br clear="none">> *lClientRequest = l_sayHello->_boxed_out();<br clear="none">> <br clear="none">> Version 2:<br clear="none">> *lClientRequest = TaskWork.m_HelloObj->sayHello()->_boxed_out();<br clear="none"><br clear="none">> ...but they don't perform the same, Version 1 doesn't cause leaks,<br clear="none">> Version 2 does.<br clear="none"><br clear="none">That is correct. It's awkward, but those are the rules of the standard<br clear="none">CORBA C++ mapping.<br clear="none"><br clear="none">[...]<br clear="none">> But going back to the original problem, why is this causing a leak<br clear="none">> when all objects are declared as _var?<br clear="none">> m_NSObj = m_ORB->resolve_initial_references("NameService");<br clear="none">> m_RootContext = CosNaming::NamingContextExt::_narrow(m_NSObj);<br clear="none"><br clear="none">If those really are both _var types, then I'm
sure it is not actually<br clear="none">leaking.<br clear="none"><br clear="none">> >> I think the LOCATION_FORWARD exception has something to do with<br clear="none">> this (upon "changing" location and retrying to resolve).<br clear="none"><br clear="none">No, the LOCATION_FORWARD will not cause it to leak. For as long as the<br clear="none">object reference is alive (which because it's an initial reference is<br clear="none">likely to be for the whole lifetime of the process), it will have<br clear="none">storage for both the original location and the forwarded location, but<br clear="none">that's not a leak.<div class="yqt7434452927" id="yqtfd64657"><br clear="none"><br clear="none">Duncan.<br clear="none"><br clear="none">-- <br clear="none"> -- Duncan Grisby --<br clear="none"> -- <a href="mailto:duncan@grisby.org" shape="rect" ymailto="mailto:duncan@grisby.org">duncan@grisby.org</a>
--<br clear="none"> -- <a href="http://www.grisby.org/" target="_blank" shape="rect">http://www.grisby.org/</a>--<br clear="none"><br clear="none"><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div> </div></body></html>