Re: Memory management question

[email protected]
Newsgroups gmane.comp.gnome.orbit.general
Message-ID <OFC4219391.6A24F436-ON85256F90.0064DA29-85256F90.00655B1B@net.sybari.com>
I'm interested in this issue as well.  I see OMG's C language mapping 
addresses argument result passing.

The last paragraph of section 1.20 states:
   For operation results of type variable-length struct, variable-length 
union, wstring, string, sequence, array, or any, the ORB will allocate 
storage for the return value using the appropriate type-specific 
allocation function.  The client may use and retain that storage 
indefinitely, and must indicate when the value is no longer needed by 
calling the procedure CORBA_free().

Regards,
Nick G.





Jules Colding <[email protected]>
Sent by: [email protected]
01/21/2005 07:43 AM
 
        To:     ORBit2 <[email protected]>
        cc: 
        Subject:        Memory management question


Hi,

I have an interface such as:

module BRUTUS {
                 union SRestriction {
                                 /* lots of variable sized stuff */
                 };

                 interface SRestrictionContainer {
                                 readonly attribute SRestriction content; 
                 }
};


The get_content() attribute method is defined as:

static BRUTUS_SRestriction 
*impl_BRUTUS_SRestrictionContainer__get_content(impl_POA_BRUTUS_SRestrictionContainer 
*servant,
  CORBA_Environment *ev)
{
        BRUTUS_SRestriction *retval;

        /* ------   insert method code here   ------ */
                 retval = &servant->attr_content;
        /* ------ ---------- end ------------ ------ */

        return retval;
}

So my question is now: Should I just return a pointer to attr_content as
I do above or should I make a copy of servant->attr_content ?


Thanks,
  jules

_______________________________________________
orbit-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/orbit-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.