. You will see that there
is no code in the release method. Then take a look at the code in
release in something like DOMElementImpl.cpp. If you trace that through
you will see what needs to be done. Be warned though, after you do this
you will fully understand xerces memory management :)
Gareth,
On Wed, 20 Oct 2004 10:11:48 +0100, Gareth Reakes
<[EMAIL PROTECTED]> wrote:
> Three options spring to mind:
>
> i) Clone the document into another document and release the first
> (although memory consumption is still an issue with 2 docs in memory)
> ii) Implement the release
> iii) Imp
Hey,
Hua-Ying Ling wrote:
On Tue, 19 Oct 2004 10:15:06 +0100, Gareth Reakes
<[EMAIL PROTECTED]> wrote:
Hi,
this is expected behavior. The rational is that recycling the
pointer/memory is expensive in comparison to the likelihood of it being
required.
That explains it. I've got a program
On Tue, 19 Oct 2004 10:15:06 +0100, Gareth Reakes
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> this is expected behavior. The rational is that recycling the
> pointer/memory is expensive in comparison to the likelihood of it being
> required.
That explains it. I've got a program where I'm accessing
Hi,
this is expected behavior. The rational is that recycling the
pointer/memory is expensive in comparison to the likelihood of it being
required.
Gareth
Hua-Ying Ling wrote:
Hi,
I find that if I run the code below in a tight loop, the memory
footprint will keep growing unless I call docume
Hi,
I find that if I run the code below in a tight loop, the memory
footprint will keep growing unless I call document->release(). Is
this expected behavior or it is a leak? If this is expected behavior
is it possible to ask Xerces to release unused memory without having
to reparse the xml file?
document. Is this safe? Or should we somehow pass the document back to the original thread with the parser to call release? Is the default memory management in place thread safe to allow the parser to keep working independently of the release of the document? Can one thread with a parser
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
eforge.net> cc:
On Wed, Oct 29, 2003 at 07:54:23AM -0800, Sean Kelly wrote:
> On Mon, 27 Oct 2003, Ronald Landheer-Cieslak wrote:
> >
> > Yes.. but only possible with Java (or more generally, when you have a garbage
> > collection mechanism in your memory management). I usually write in C
On Mon, 27 Oct 2003, Ronald Landheer-Cieslak wrote:
>
> Yes.. but only possible with Java (or more generally, when you have a garbage
> collection mechanism in your memory management). I usually write in C or C++
> and don't have the luxury of a memory manager, let alone a
On Mon, Oct 27, 2003 at 06:46:01AM -0800, James Berry wrote:
> On Oct 27, 2003, at 6:00 AM, Ronald Landheer-Cieslak wrote:
>
> > Q: what's the alignment I should use?
> > A: something smaller than the size of a pointer - like zero!
> >Result: part of - or everything of - the pointer can (a
On Oct 27, 2003, at 6:00 AM, Ronald Landheer-Cieslak wrote:
Q: what's the alignment I should use?
A: something smaller than the size of a pointer - like zero!
Result: part of - or everything of - the pointer can (and will) be
overwritten
with user data. Thinking of it a bit more, I think a patc
#x27;s garbage collection to
> avoid having to lock the list during deletions. Nice.)
Yes.. but only possible with Java (or more generally, when you have a garbage
collection mechanism in your memory management). I usually write in C or C++
and don't have the luxury of a memory manager, let
On Thu, Oct 23, 2003 at 09:49:34AM -0700, James Berry wrote:
> Congratulations on the birth of your daughter.
Thanks :)
> The semantics of "here's the alignment that should be applied to a
> newly allocated block" versus "here's some details of how you&
> From: Ronald Landheer-Cieslak [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 23, 2003 1:14 PM
> On Wed, Oct 22, 2003 at 07:26:07PM -0700,
> [EMAIL PROTECTED] wrote:
> > If you want to update [a reference counter], I don't see how you can
> > guarantee updates will not collide [without loc
s some easily documentable and handy properties to not aligning,
which
IMHO is the behaviour one would expect from setting
XML_PLATFORM_NEW_BLOCK_ALIGNMENT to 0.
Congratulations on the birth of your daughter.
The semantics of "here's the alignment that should be applied to a
newly allocat
On Wed, Oct 22, 2003 at 07:26:07PM -0700, [EMAIL PROTECTED] wrote:
> > There is no need to synchronize access to make a reference container
> > thread-safe.
> If you want to update it, I don't see how you can guarantee updates will
> not collide, but I'm willing to be educated, if you can provide a
On Thu, Oct 23, 2003 at 06:24:34AM -0700, James Berry wrote:
> I don't particularly like the idea of overloading the alignment define
> to serve a completely different purpose. Yes, 0 is an illegal value for
> this define, (it would presumably result in a divide by zero as we take
> ptrSize %
Ronald,
I don't particularly like the idea of overloading the alignment define
to serve a completely different purpose. Yes, 0 is an illegal value for
this define, (it would presumably result in a divide by zero as we take
ptrSize % alignment). But that doesn't mean it's a good idea to
ove
ping!
This patch has been on the list for a couple of days now - comments?
It's pretty straight-forward, actually: if the platform new block alignment
is 0, the global manager (or the one passed to the delete operator, whichever
best applies) is always used for deleting - which makes sense becaus
> On Fri, Oct 17, 2003 at 10:11:48AM -0700, [EMAIL PROTECTED]
wrote:
> > > The XMemory class uses a global memory manager class thet defaults to
> > > MemoryManagerImpl. This latter is in charge of allocating and freeing
> > > memory and will return a pointer to that memory to XMemory. XMemory
I have attached the patch described below:
On Mon, Oct 20, 2003 at 01:38:55PM +0200, Ronald Landheer-Cieslak wrote:
> On Fri, Oct 17, 2003 at 10:11:48AM -0700, [EMAIL PROTECTED] wrote:
> > You can already get compile-time alignment through a #define, which you
> > could also define to be 0, which
On Fri, Oct 17, 2003 at 10:11:48AM -0700, [EMAIL PROTECTED] wrote:
> > The XMemory class uses a global memory manager class thet defaults to
> > MemoryManagerImpl. This latter is in charge of allocating and freeing
> > memory and will return a pointer to that memory to XMemory. XMemory
> > does so
> The XMemory class uses a global memory manager class thet defaults to
> MemoryManagerImpl. This latter is in charge of allocating and freeing
memory
> and will return a pointer to that memory to XMemory. XMemory does some
> management of its own, however, "aligning" the pointer it returns by
Hello all,
We recently switched from Xerces-C2.2 to Xerces-C2.3 for some of our products'
XML parsing and are having problems with the memory management features.
When running a COM object that uses Xerces-C2.3 (DOM or SAX - we use them both
in different objects with the same results) on
gzilla/show_bug.cgi?id=20615
Memory Management
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=20615
Memory Management
Summary: Memory Management
Product: Xerces-C++
Version: 2.3.0
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Uti
gzilla/show_bug.cgi?id=13437
Incorrect memory management in LinuxPlatformUtils.cpp
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PRO
ow.
Sarah
-Original Message-
From: Widi Sagita [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 20, 2002 4:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Clarification needed on DOM memory management
hello all,
i'm really newbie in xerces
i've already install xerces 2.1.0 and i think it'
ay, December 20, 2002 1:56 AM
> To: '[EMAIL PROTECTED]'
> Subject: Re: Clarification needed on DOM memory management
>
> Hi Dan,
>
> > I have two questions:
> > 1. Does "implementation" mean *my* application code or does it mean the
> > Xerces develop
hello all,
i'm really newbie in xerces
i've already install xerces 2.1.0 and i think it's work
but when i try to build the samples directory, error occured..
for information, i use SCO OpenServer 5.0.6
gcc ver 2.95.2
installation configuration: runConfigure -popenserver -cgcc -xg++ -rnone -nsocke
Hi Dan,
> I have two questions:
> 1. Does "implementation" mean *my* application code or does it mean the
> Xerces developed DOM implementation?
If you do not do anything then the document will delete all the allocated
memory when it is deleted (As long as you have not adopted the document).
The documentation at
http://xml.apache.org/xerces-c/program-dom.html#DOMMemMgmt says:
"Memory for any returned object are owned by implementation."
Also, the documentation at
http://xml.apache.org/xerces-c/ApacheDOMC++BindingL2.html says:
"
C++ Memory Management:
gzilla/show_bug.cgi?id=13437
Incorrect memory management in LinuxPlatformUtils.cpp
Summary: Incorrect memory management in LinuxPlatformUtils.cpp
Product: Xerces-C++
Version: 2.1.0
Platform: All
OS/Version: Linux
Status: NEW
Se
Hi,
I'm sorting memory management for the XPath node in Pathan2 and
thought I'd model the attribute way of doing things. I want to confirm
what I have found out as it seems a touch strange. When you remove and
element and then release it it deletes all of its children bu
gzilla/show_bug.cgi?id=7675
IDOM memory management problem
Summary: IDOM memory management problem
Product: Xerces-C++
Version: 1.7.0
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Com
delete myDocument is enough.
Tinny
Vinodkumar S wrote:
> I have a small doubt in its memory management , let take an example like
> this
> // C++ IDOM - explicit deletion
> IDOM_Document* myDocument;
> IDOM_Node* aNode;
> myDocument = IDOM_DOMImplementation:
I have a small doubt in its memory management , let take an example like
this
// C++ IDOM - explicit deletion
IDOM_Document* myDocument;
IDOM_Node* aNode;
myDocument = IDOM_DOMImplementation::getImplementation()->createDocument();
aNode = myDocument->createElement("
nny
"Houle, Dennis W" wrote:
> Team Xerces-C,
> As I understand memory management in IDOM, the IDOM_Document allocates heap
> memory for XMLCh* returned from such methods as IDOM_Element::getAttribute
> and does not deallocate heap memory until the IDOM_Document destructor is
>
Team Xerces-C,
As I understand memory management in IDOM, the IDOM_Document allocates heap
memory for XMLCh* returned from such methods as IDOM_Element::getAttribute
and does not deallocate heap memory until the IDOM_Document destructor is
called.
So does this mean that the heap will grow
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-
t 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?
&g
As far as I know, you are correct in thinking that this code would work.
However, extreme caution should be taken over using code like this. I am
currently working on a project which uses similar reference counting,
and bugs in the this code are the hardest bugs we have had to track
down.
Surely
On Wed, Apr 11, 2001 at 12:31:58PM -0400, [EMAIL PROTECTED] wrote:
>
> >Why can't I 'new' dom objects? Is this wrong practise
> >unconditionally, or I only must be very careful?
>
> Wrong practice pretty much unconditionally, unless you're a parser or
> otherwise need to access things in ways th
lly use new and delete, then the built-in garbage
> collection won't work because the reference counting will be wrong.
I understand about reference counting, but I cannot get how
new and delete in the example below will fool memory
management. Or xerces use garbage collection that looks
at a
On Wed, Apr 11, 2001 at 04:26:09PM -0400, Cem Karan wrote:
> Anyone who wants to jump in and correct me, please do so.
>
> Xerces tries to use reference counting wherever possible to
> automatically dispose of unused memory in much the same way that Java
> does it. If you actually use new and de
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&
>Why can't I 'new' dom objects? Is this wrong practise
>unconditionally, or I only must be very careful?
Wrong practice pretty much unconditionally, unless you're a parser or
otherwise need to access things in ways that the DOM APIs explicitly forbid
for normal applications. The factory methods
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
49 matches
Mail list logo
