Hi Jason, Looks like you should avoid the handles, stick to the raw pointer interface, and expose release though your interface.
> Sorry, I guess I wasn't clear, what I mean is that there will be a > documented way for people to use the smart pointer interface to DOM > that does automatic memory collection. If Xerces-Perl is unable to > support that, then people will try it anyway and get confused. I think Tinny was suggesting that the primary documented interface would be the updated IDOM. I would expect some limited verbiage be applied to how to use handles in your application as a way to gain automated memory management, but all of the examples would be without handles. Those examples would have to make it clear which circumstances calls to release are beneficial in manually managing resources. So long as you note to users of your binding that handles are not used, then they should not be confused. BTW, Tinny has expressed that it is more important for the handles to be backwards compatible with the original DOM than to be a simpler implementation, which the smart pointer approach would have provided. So the handles will not be smart pointers after all. Not that you care for your purpose, just that we have been talking about them as smart pointers and I just wanted to make that clear. Lenny -----Original Message----- From: Jason E. Stewart [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 2:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Call for Vote: which one to be the Xerces-C++ public supported W3C DOM interface "Lenny Hoffman" <[EMAIL PROTECTED]> writes: > > The issue is what I would need to do to keep a smart pointer. > > Sorry, I haven't used SWIG. Does SWIG only work with pointers? It isn't a limitation of SWIG, it is an issue of how Perl wraps C/C++ objects/structs, Perl demands a pointer. > Specifically can perl_sv_setref_pv be modified to take nodes by > value instead of by pointer? For example would the following work?: > > some_wrapper_method () > { > DOM_Element element = ...; > SV *perl_object = perl_sv_setref_pv('DOM_Element', element); > ... // return perl_object > } No, Perl demands a pointer. I don't see how you could do it otherwise. Perl knows nothing about Xerces or DOM_Element, so how could I have a function that took an object of type DOM_Element and get it to compile, unless it was cast to a void*? Maybe I'm just lacking creativity, but I don't see how else it could be done. If you can suggest an alternative, I'd be extremely interested to hear it. > By passing element by value, its behavior as a smart pointer is to not copy > the actual node implementation, but properly update its reference > count. What I could do, I suppose is invoke the copy constructor: some_wrapper_method () { DOM_Element element = ...; SV *perl_object = perl_sv_setref_pv('DOM_Element', (void*)DOM_Element(element)); ... // return perl_object } > > It seems I will *have* to force users to explicitly call > > release(), and that will mean the Xerces-C DOM API has > > functionality not replicated in Xerces-Perl, which is likely to > > lead to user confusion for me. > > Since release would be part of the Xerces-C DOM API, your replicating it > should lead to no user confusion. Sorry, I guess I wasn't clear, what I mean is that there will be a documented way for people to use the smart pointer interface to DOM that does automatic memory collection. If Xerces-Perl is unable to support that, then people will try it anyway and get confused. > How did you get SWIG to work with the original DOM interface? That > interface is really a handle interface, so working with these > handles (as smart pointers not withstanding) should work in a > similar way. Then you can get automatic memory management and not > bother your users with having to call release. Yes, good point. Xerces-Perl handled it rather badly I'm afraid. I never looked into it properly, because I knew that IDOM was coming, but basically there was very poor performance, because any method that returned a handle had to immediately invoke the copy contstructor for that class to get back a pointer, so there was a *lot* of unnecessary copying. But also, the memory issues were pretty wierd - I was convinced that memory was not being properly released but never made time to properly debug it (because IDOM was coming). So raw pointers are much simpler for me, much less copying, and the memory management is explicit. When I'm done with a node, I call release. jas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
