Thanks Aaaron for sharing your memory management solution.
The approach I'm considering is somewhat similar. My DOM wrapper class
would maintain an array of DOM_Documents that have been parsed. Wrapper
class accessor operations would receive and output DOM_Node values that have
been re-typed to a public NodeKey type. Users of the DOM wrapper class do
not manipulate NodeKeys, only pass them in and out of the DOM wrapper class
operations (e.g. receive a NodeKey from a getChild() operation and pass it
back as a parameter to a getAttribute() operation).
I'm hoping that by maintaining the internal DOM_Document array, DOM will
maintain the entire document on the heap and nodes won't disappear as the
local DOM_Node variables in the DOM wrapper accessor operations go out of
scope. This approach would eliminate the need to maintain a DOM_Node array
containing an element for each node of the document.
I haven't prototyped this scheme yet, so this is all still conjecture on my
part.
Any comments on this memory management approach, or other memory management
success stories would be much appreciated.
- Dennis
-----Original Message-----
From: Aaron Kaplan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 18, 2001 8:04 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: memory management
On Wed, 11 Apr 2001, Konstantin Kivi wrote:
> From the xerces docs:
> >Key points to remember when using the C++ DOM classes:
> > Create them as local variables, or as member
> > variables of some other class. Never "new" a
> > DOM object into the heap or make an ordinary C
> > pointer variable to one, as this will greatly
> > confuse the automatic memory management.
>
> Why can't I 'new' dom objects? Is this wrong practise
> unconditionally, or I only must be very careful?
>
> what is the difference between
>
> {
> DOM_Document *pdoc=new
> DOM_Document(impl.createDocument(...));
>
> ...........................
> delete pdoc;
> }
>
> and
> {
> DOM_Document doc=impl.createDoc(...);
> ......................
>
> }
>
> why I can make those objects being parts of the
> stucture and then alloc the that structure?
> (the doc doesn't say I can't do so)
>
> What I exactly need is to pass the pointer
> to DOM_Document or its equivalent (call it handle)
> between C and C++ parts of the programm.
No, it is not a stupid question.... I had to fight with the same problem
for 2 weeks until it worked. Mem mgmt on xerces is probably a good idea
by itself but as soon as you want to interface with other langs it turns
out to be a terrible thing which is always in the way.
Ok, here is how I was sucessfull:
write a (C++) wrapper class. The class has an array
(lets call it my_dom_node_refs_workaround_array, or simply "arr" for
short):
class wrapper {
private:
Dom_Node arr[MAX_NODES];
unsigned int last_arr_idx; // last used array index
}
when you want to keep a DOM_Node somewhere simply go like this:
arr[last_arr_idx++] = my_dom_node;
so whenever you want to pass a pointer/reference to the calling C program
you would return the _array_index and not the address of the DOM_Node.
When your calling C program is finished, let it call a cleanup method:
class wrapper {
public:
BOOL cleanup() {
for (int i = 0; i < MAX_NODES; i++) {
arr[i] = 0; // by this the node references will be decremented
// and eventually all DOM_Node mem will be freed
} // end for
} // end func
} // end class
>
hope it helped,
aaron.
> Sorry if I am asking something really stupid
>
> --
> Sincerely Yours, Konstantin Kivi, Russia, [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
