Hi Jason,
> 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? 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
}
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.
The reason that I figured that using smart pointers would mean fewer updates
for you than using handles that were not is because current code you have
like this:
IDOM_Element* element = ...;
IDOM_Node* node = element->getFirstChild();
would become (assuming a different naming convention for handles as smart
pointers):
DOMElementH element = ...;
DOMNodeH node = element->getFirstChild();
as compared to (handles not as smart pointers):
DOM_Element element = ...;
DOM_Node node = element.getFirstChild();
Note that the handle as a smart pointer allows you to continue to use the ->
operator as if you were still working with raw pointers. This means that
going to handles as smart pointers requires only one type of change, where
going to handles as full interface (backwards compatible with original DOM)
would require two types of change.
> 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.
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.
Lenny
-----Original Message-----
From: Jason E. Stewart [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 12:02 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:
> Am I missing something here?
Probably, not ;-)
It's usually my lack of C++ knowledge.
> > To track the underlying C++ objects, Xerces-Perl keeps a pointer
> > to the object, so all my method calls will be pointer invocations.
>
> I don't understand what the problem is. You can continue to keep a
pointer,
> or you can keep a smart pointer.
The issue is what I would need to do to keep a smart pointer.
I use SWIG to generate all my wrapper code - so in some sense I am
constrained by how SWIG generates wrappers. Let's for a moment forget
this, and say I was doing it by hand.
If my wrapper code generated smart pointers like so:
some_wrapper_method ()
{
DOM_Element element = ...;
SV *perl_object = perl_sv_setref_pv('DOM_Element', &element);
... // return perl_object
}
how will the smart pointer know that it hasn't gone out of scope and
release itself automatically, thus leaving me with a bad pointer?
> I thought you said you currently support the IDOM. If you are happy with
> that, then all you need to do is renamed IDOM_* to DOM*.
already done.
> You don't have to use the smart pointer handles if you don't want
> the benefit of automatic calls to release, either because you will
> be explicitly calling release when needed or you don't care about
> memory growth.
;-)
Believe me I would like automatic memory release, I'm just at a loss
to figure out how I can get to it. 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.
> If you did decide to gain the benefit of handles, then their being
> smart pointers would mean fewer updates for you, not more, as the
> handles as smart pointers act quite a bit like the raw pointers you
> are using today.
If you can help me understand how to use them, then I will be very
happy.
Pardon my denseness,
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]
