"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]
