So it sounds like dynamic construction of DOM objects is allowed
by Xerces and its memory management is not affected by an
application using new with default or copy constructors. Of course
DOM implementation objects can only be created through factory
methods. Should Xerces docs be updated to clarify such usage?
I have updated my sample program to show dynamic default and
copy construction of a DOM_Node. Program output is also shown.
Thanks,
Zartaj
/***************************************/
#include <string>
#include <iostream>
#include <util/PlatformUtils.hpp>
#include <dom/DOM_DOMException.hpp>
#include <dom/DOM_Node.hpp>
#include <dom/DOM_Document.hpp>
#include <dom/DOMString.hpp>
DOM_Node *fp(const std::string &text)
{
DOM_Document d = DOM_Document::createDocument();
DOM_Node n = d.createTextNode(text.c_str());
//n.fImpl->nodeRefCount = 2
DOM_Node *np = new DOM_Node(n);
//np->fImpl->nodeRefCount = 3
std::cout << "fp(np): " << np->getNodeValue().transcode() << "\n";
return np;
}
int main(int argc, char *argv[])
{
try {
XMLPlatformUtils::Initialize();
} catch (const XMLException& toCatch) {
std::cerr << "main: Error during initialization! :\n";
return 1;
}
DOM_Node *np = fp("NewTextNode");
//np->fImpl->nodeRefCount = 1
std::cout << "main(np): " << np->getNodeValue().transcode() << "\n";
DOM_Node *npd = new DOM_Node;
*npd = *np;
//npd->fImpl->nodeRefCount = 2
std::cout << "main(npd): " << npd->getNodeValue().transcode() << "\n";
DOM_Node n(*np);
//n.fImpl->nodeRefCount = 3
std::cout << "main(n): " << n.getNodeValue().transcode() << "\n";
delete np;
//n.fImpl->nodeRefCount = 2
delete npd;
//n.fImpl->nodeRefCount = 1
return 0;
}
/***********************************************/
$ ./xerces_test
fp(np): NewTextNode
main(np): NewTextNode
main(npd): NewTextNode
main(n): NewTextNode
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 31, 2001 7:13 AM
To: [EMAIL PROTECTED]
Subject: Re: Why not new DOM_Node?
Yes, it will work, but you must be very careful about passing that pointer
around. Aliasing a smart pointer defeats the purpose of having
reference-counting, since your application must now keep track of how many
copies of the pointer are still reachable.
It can also be less efficient, since you are using dynamic memory
allocation for a very small object. If you end up doing lots of these, it
will be very expensive.
It's also a conceptual problem, since you now have a pointer to a
smart-pointer. Imagine this:
DOM_Node* const np = foo();
if (np != 0 && np->isNull() == false)
{
....
}
To be safe, I need to check for a null pointer, and a null smart-pointer.
That's pretty nasty.
Dave
zartaj.majeed@
kanisa.com To:
[EMAIL PROTECTED]
cc: (bcc: David N
Bertoni/CAM/Lotus)
05/30/2001 Subject: Why not new DOM_Node?
05:29 PM
Please respond
to
xerces-c-dev
Xerces-C docs say an application should never new a DOM object since "this
will
greatly confuse the automatic memory management". I'd appreciate if someone
could elaborate on how Xerces memory management could be thrown off by an
application newing a DOM instance.
It seems Xerces reference counting should work even if a DOM instance is
new'd.
The new will increment the reference count and the reference count cannot
go
to
zero before a corresponding delete is done.
Below is a simple scenario in which a DOM_Node pointer works. Why won't it
work
in other situations?
One reason it would be nice to use pointers is to remove dependencies on
Xerces
headers by using DOM_Node * instead of DOM_Node data members.
Thanks,
Zartaj
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
