On Sun, Oct 31, 2004 at 05:21:29PM -0800, [EMAIL PROTECTED] wrote:
> > Afaik, when overloading 'placement' new and delete
> > like that, the only time the corresponding overload
> > of delete will be called is if the constructor throws.
> > All other times you have to call the destructor and
> > th
> Afaik, when overloading 'placement' new and delete
> like that, the only time the corresponding overload
> of delete will be called is if the constructor throws.
> All other times you have to call the destructor and
> the right version of delete yourself.
This is not true. If a class implements
On Sun, Oct 31, 2004 at 10:18:54AM -0800, [EMAIL PROTECTED]
wrote:
> > > All classes that derive from XMemory use "placement" new with a
> > > MemoryManager instance, and the normal delete expression. The
> > > call
> stack
> > > you posted looks fine.
> >
> > But is this the correct behaviour
Hi Graham,
> > All classes that derive from XMemory use "placement" new with a
> > MemoryManager instance, and the normal delete expression. The call
stack
> > you posted looks fine.
>
> But is this the correct behaviour? I think the destructor for the
> object should be called, then the op
On Sat, Oct 30, 2004 at 09:20:46PM -0400, [EMAIL PROTECTED] wrote:
> > I'm seeing a crash when an IGXMLScanner held statically is destroyed.
> > I'm using Xerces 2.3.0 on linux compiled with gcc 3.2.
>
> Can you elaborate on what you mean by "held statically?" You shouldn't
> have any static ins
> I'm seeing a crash when an IGXMLScanner held statically is destroyed.
> I'm using Xerces 2.3.0 on linux compiled with gcc 3.2.
Can you elaborate on what you mean by "held statically?" You shouldn't
have any static instance of Xerces-C classes, as they cannot be created
before the library is i
Hi all,
I'm seeing a crash when an IGXMLScanner held statically is destroyed.
I'm using Xerces 2.3.0 on linux compiled with gcc 3.2. The stack
trace is as follows:
#0 0x4123e679 in chunk_free (ar_ptr=0x412f2500, p=0x810da08) at
malloc.c:3243
#1 0x4123e424 in __libc_free (mem=0x810da10) at mal