You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Khaled Noaman <kn...@ca.ibm.com> on 2003/04/09 21:30:16 UTC
Configurable Memory Manager
Hi everyone,
We have a request for a configurable memory management at static
initialization and parser instance level. I thought that I would post the
requirement and proposed design to the mailing list to gather feedback.
Requirement:
-------------
Configurable memory management at the static initialization and parser
instance level. This means all memory a parser might allocate directly
or indirectly would come from a user supplied heap. When doing static
initialization, users can supply a heap, which can be used for all static
initialization as well as for memory allocation by static functions. This
will allow users to control memory allocated for static instances as well
as by static methods. A memory manager, per parser instance model
ensures that if a parser leaks while parsing a document, we can just
delete it and throw away the heap. This feature will make Xerces-C++
more robust.
Design Assumptions:
---------------------
1. The pluggable memory manager for static initialization will be set only
once during the initialization for Xerces-C++
2. The external application owns the memory manager.
3. The external application is responsible for the thread safety of the
memory allocation and deallocation.
4. Immutable memory manager/parser instance
(i.e. no re-specification of memory managers on parsers)
Design Overview:
------------------
1. Provide a memory manager interface that external applications can
implement
2. Provide a default implementation that will be used if application do
not provide their own memory manager.
3. Allow for setting application's memory manager during static initialization
4. Allow applications to plug-in their own memory managers per parser
instance level.
5. Override class specific operator new and delete
6. Hold instance of memory manager in classes that need to allocate
dynamic memory.
7. Other considerations
Design Details:
--------------
1. Memory manager interface
class MemoryManager
{
public:
virtual ~MemoryManager() {}
virtual void* allocate(size_t size) = 0;
virtual void deallocate(void* p) = 0;
protected :
MemoryManager() {}
private:
MemoryManager(const MemoryManager&);
MemoryManager& operator=(const MemoryManager&);
};
2. Default implementation
class MemoryManagerImpl : public MemoryManager
{
public:
MemoryManagerImpl() {}
virtual ~MemoryManagerImpl() {}
virtual void* allocate(size_t size);
virtual void deallocate(void* p);
private:
MemoryManagerImpl(const MemoryManagerImpl&);
MemoryManagerImpl& operator=(const MemoryManagerImpl&);
};
void* MemoryManagerImpl::allocate(size_t size)
{
return ::operator new(size);
}
void MemoryManagerImpl::deallocate(void* p)
{
::operator delete(p);
}
3. Xerces-C++ initiliazation
MemoryManager* XMLPlatformUtils::fgMemoryManager = 0;
bool XMLPlatformUtils::fgMemMgrAdopted = true;
void XMLPlatformUtils::Initialize(const char* const
locale
, const
char* const nlsHome
,
PanicHandler* const panicHandler
,
MemoryManager* const memMgr)
{
//
// Effects of overflow:
// . resouce re-allocations
// . consequently resource leaks
// . potentially terminate() may never get executed
//
// We got to prevent overflow from happening.
// no error or exception
//
if (gInitFlag == LONG_MAX)
return;
// Set pluggable memory manager
if (!fgMemoryManager) {
if (memMgr) {
fgMemoryManager = memMgr;
fgMemMgrAdopted = false;
}
else {
fgMemoryManager = new MemoryManagerImpl();
}
}
....
....
}
void XMLPlatformUtils::Terminate()
{
....
....
if (fgMemMgrAdopted)
delete fgMemoryManager;
else
fgMemMgrAdopted = true;
// And say we are no longer initialized
gInitFlag = 0;
}
4. Memory manager per parser instance
Part of it is achieved in point 6. For other parsers that are not
created directly,
we modify the factory methods to take the manager as a parameter.
e.g. // SAX2
createXMLReader
(
MemoryManger* memMgr = XMLPlatformUtils::fgMemoryManager
);
5. Override class specific new/delete operators.
Introduce a new class, let's call it XMemory, that overrides C++ operator
new and delete, and have that class be the base of many of Xerces-C++
classes.
class XMemory
{
public :
void* operator new(size_t size);
void* operator new(size_t size, MemoryManager* memMgr);
void operator delete(void* p);
void operator delete(void* p, MemoryManager* memMgr);
protected :
XMemory() {}
private:
XMemory(const XMemory&);
XMemory& operator=(const XMemory&);
};
void* XMemory::operator new(size_t size)
{
void* const block = XMLPlatformUtils::fgMemoryManager->allocate
(
size + sizeof(MemoryManager*)
);
*(MemoryManager**)block = XMLPlatformUtils::fgMemoryManager;
return (char*)block + sizeof(MemoryManager*);
}
void* XMemory::operator new(size_t size, MemoryManager* manager)
{
assert(manager != 0);
void* const block = manager->allocate(size +
sizeof(MemoryManager*));
*(MemoryManager**)block = manager;
return (char*)block + sizeof(MemoryManager*);
}
void XMemory::operator delete(void* p)
{
if (p != 0)
{
void* const block = (char*)p - sizeof(MemoryManager*);
MemoryManager* const manager = *(MemoryManager**)block;
assert(manager != 0);
manager->deallocate(block);
}
}
void XMemory::operator delete(void* p, MemoryManager* memMgr)
{
assert(p != 0 && manager != 0);
assert
(
*(XercesMemoryManager**)((char*)p -
sizeof(XercesMemoryManager*))
== manager
);
manager->deallocate((char*)p - sizeof(XercesMemoryManager*));
}
6. Hold instance of memory manager
Modify constructors of Xerces-C++ classes to add a memory manager that
is defaulted to the static instance.
e.g.
XMLScanner
(
XMLValidator* const valToAdopt
, MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
);
7. Other considerations
For all calls to operator new [] and delete[], use the memory manager to
allocate/deallocate the memory
e.g.
XMLCh* name = new XMLCh[10];
--> XMLCh* name = memMgr->allocate(10 * sizeof(XMLCh));
delete [] name; --> memMgr->deallocate(name);
Modify DOMImplementation factory methods to pass in the memory manager
e.g.
createDocument
(
MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
);
Some open Questions:
-----------------------
* Where do we store the instance of the memory manager for classes that do
need dynamic memory allocation? (per class or at the base class XMemory)
Your comments and suggestions are appreciated.
Khaled
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Configurable Memory Manager
Posted by James Berry <jb...@criticalpath.com>.
On 5/15/03 1:43 PM, "Khaled Noaman" <kn...@ca.ibm.com> wrote:
> Hi James,
>
> I know how huge the changes are.
Yes, I'm certain you do...since you made them ;)
>But, the requirment is to have a memory
> manager per
> parser instance. It would have been much easier, if we had a static instance
> of a
> memory manager to be for all of Xerces-C++. We already have a static instance,
> that's set during XMLPlatformUtils::Initialize and is used for static
> initialization
> and by static methods.
Okay, I guess I glossed over that ;)
James.
>
> Khaled
>
> James Berry wrote:
>
>> Khaled,
>>
>> Watching your checkins for the memory manager changes, I'm somewhat shocked
>> by the changes required, and by the degree to which it seems this memory
>> manager needs to be passed around, into routines, etc.
>>
>> Is there a way to eliminate that passing around of the memory manager by
>> making a global that can be accessed through a static function (and perhaps
>> also providing static functions for allocate and delete?).
>>
>> -jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Configurable Memory Manager
Posted by Khaled Noaman <kn...@ca.ibm.com>.
Hi James,
I know how huge the changes are. But, the requirment is to have a memory manager per
parser instance. It would have been much easier, if we had a static instance of a
memory manager to be for all of Xerces-C++. We already have a static instance,
that's set during XMLPlatformUtils::Initialize and is used for static initialization
and by static methods.
Khaled
James Berry wrote:
> Khaled,
>
> Watching your checkins for the memory manager changes, I'm somewhat shocked
> by the changes required, and by the degree to which it seems this memory
> manager needs to be passed around, into routines, etc.
>
> Is there a way to eliminate that passing around of the memory manager by
> making a global that can be accessed through a static function (and perhaps
> also providing static functions for allocate and delete?).
>
> -jdb
>
> On 4/9/03 12:30 PM, "Khaled Noaman" <kn...@ca.ibm.com> wrote:
>
> > Hi everyone,
> >
> > We have a request for a configurable memory management at static
> > initialization and parser instance level. I thought that I would post the
> > requirement and proposed design to the mailing list to gather feedback.
> >
> > Requirement:
> > -------------
> > Configurable memory management at the static initialization and parser
> > instance level. This means all memory a parser might allocate directly
> > or indirectly would come from a user supplied heap. When doing static
> > initialization, users can supply a heap, which can be used for all static
> > initialization as well as for memory allocation by static functions. This
> > will allow users to control memory allocated for static instances as well
> > as by static methods. A memory manager, per parser instance model
> > ensures that if a parser leaks while parsing a document, we can just
> > delete it and throw away the heap. This feature will make Xerces-C++
> > more robust.
> >
> > Design Assumptions:
> > ---------------------
> > 1. The pluggable memory manager for static initialization will be set only
> > once during the initialization for Xerces-C++
> > 2. The external application owns the memory manager.
> > 3. The external application is responsible for the thread safety of the
> > memory allocation and deallocation.
> > 4. Immutable memory manager/parser instance
> > (i.e. no re-specification of memory managers on parsers)
> >
> > Design Overview:
> > ------------------
> > 1. Provide a memory manager interface that external applications can
> > implement
> > 2. Provide a default implementation that will be used if application do
> > not provide their own memory manager.
> > 3. Allow for setting application's memory manager during static initialization
> > 4. Allow applications to plug-in their own memory managers per parser
> > instance level.
> > 5. Override class specific operator new and delete
> > 6. Hold instance of memory manager in classes that need to allocate
> > dynamic memory.
> > 7. Other considerations
> >
> > Design Details:
> > --------------
> > 1. Memory manager interface
> >
> > class MemoryManager
> > {
> > public:
> > virtual ~MemoryManager() {}
> >
> > virtual void* allocate(size_t size) = 0;
> > virtual void deallocate(void* p) = 0;
> >
> > protected :
> > MemoryManager() {}
> >
> > private:
> > MemoryManager(const MemoryManager&);
> > MemoryManager& operator=(const MemoryManager&);
> > };
> >
> > 2. Default implementation
> >
> > class MemoryManagerImpl : public MemoryManager
> > {
> > public:
> >
> > MemoryManagerImpl() {}
> > virtual ~MemoryManagerImpl() {}
> >
> > virtual void* allocate(size_t size);
> > virtual void deallocate(void* p);
> > private:
> > MemoryManagerImpl(const MemoryManagerImpl&);
> > MemoryManagerImpl& operator=(const MemoryManagerImpl&);
> > };
> >
> > void* MemoryManagerImpl::allocate(size_t size)
> > {
> > return ::operator new(size);
> > }
> >
> > void MemoryManagerImpl::deallocate(void* p)
> > {
> > ::operator delete(p);
> > }
> >
> > 3. Xerces-C++ initiliazation
> >
> > MemoryManager* XMLPlatformUtils::fgMemoryManager = 0;
> > bool XMLPlatformUtils::fgMemMgrAdopted = true;
> >
> > void XMLPlatformUtils::Initialize(const char* const
> > locale
> > , const
> > char* const nlsHome
> > ,
> > PanicHandler* const panicHandler
> > ,
> > MemoryManager* const memMgr)
> > {
> > //
> > // Effects of overflow:
> > // . resouce re-allocations
> > // . consequently resource leaks
> > // . potentially terminate() may never get executed
> > //
> > // We got to prevent overflow from happening.
> > // no error or exception
> > //
> > if (gInitFlag == LONG_MAX)
> > return;
> >
> > // Set pluggable memory manager
> > if (!fgMemoryManager) {
> > if (memMgr) {
> > fgMemoryManager = memMgr;
> > fgMemMgrAdopted = false;
> > }
> > else {
> > fgMemoryManager = new MemoryManagerImpl();
> > }
> > }
> > ....
> > ....
> > }
> >
> > void XMLPlatformUtils::Terminate()
> > {
> > ....
> > ....
> >
> > if (fgMemMgrAdopted)
> > delete fgMemoryManager;
> > else
> > fgMemMgrAdopted = true;
> >
> > // And say we are no longer initialized
> > gInitFlag = 0;
> > }
> >
> > 4. Memory manager per parser instance
> >
> > Part of it is achieved in point 6. For other parsers that are not
> > created directly,
> > we modify the factory methods to take the manager as a parameter.
> >
> > e.g. // SAX2
> > createXMLReader
> > (
> > MemoryManger* memMgr = XMLPlatformUtils::fgMemoryManager
> > );
> >
> > 5. Override class specific new/delete operators.
> >
> > Introduce a new class, let's call it XMemory, that overrides C++ operator
> > new and delete, and have that class be the base of many of Xerces-C++
> > classes.
> >
> > class XMemory
> > {
> > public :
> > void* operator new(size_t size);
> > void* operator new(size_t size, MemoryManager* memMgr);
> > void operator delete(void* p);
> > void operator delete(void* p, MemoryManager* memMgr);
> >
> > protected :
> > XMemory() {}
> >
> > private:
> > XMemory(const XMemory&);
> > XMemory& operator=(const XMemory&);
> > };
> >
> > void* XMemory::operator new(size_t size)
> > {
> > void* const block = XMLPlatformUtils::fgMemoryManager->allocate
> > (
> > size + sizeof(MemoryManager*)
> > );
> >
> > *(MemoryManager**)block = XMLPlatformUtils::fgMemoryManager;
> >
> > return (char*)block + sizeof(MemoryManager*);
> > }
> >
> > void* XMemory::operator new(size_t size, MemoryManager* manager)
> > {
> > assert(manager != 0);
> >
> > void* const block = manager->allocate(size +
> > sizeof(MemoryManager*));
> > *(MemoryManager**)block = manager;
> >
> > return (char*)block + sizeof(MemoryManager*);
> > }
> >
> > void XMemory::operator delete(void* p)
> > {
> > if (p != 0)
> > {
> > void* const block = (char*)p - sizeof(MemoryManager*);
> >
> > MemoryManager* const manager = *(MemoryManager**)block;
> > assert(manager != 0);
> > manager->deallocate(block);
> > }
> > }
> >
> > void XMemory::operator delete(void* p, MemoryManager* memMgr)
> > {
> > assert(p != 0 && manager != 0);
> > assert
> > (
> > *(XercesMemoryManager**)((char*)p -
> > sizeof(XercesMemoryManager*))
> > == manager
> > );
> >
> > manager->deallocate((char*)p - sizeof(XercesMemoryManager*));
> > }
> >
> > 6. Hold instance of memory manager
> >
> > Modify constructors of Xerces-C++ classes to add a memory manager that
> > is defaulted to the static instance.
> > e.g.
> > XMLScanner
> > (
> > XMLValidator* const valToAdopt
> > , MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
> > );
> >
> > 7. Other considerations
> >
> > For all calls to operator new [] and delete[], use the memory manager to
> > allocate/deallocate the memory
> > e.g.
> > XMLCh* name = new XMLCh[10];
> > --> XMLCh* name = memMgr->allocate(10 * sizeof(XMLCh));
> >
> > delete [] name; --> memMgr->deallocate(name);
> >
> > Modify DOMImplementation factory methods to pass in the memory manager
> > e.g.
> > createDocument
> > (
> > MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
> > );
> >
> > Some open Questions:
> > -----------------------
> > * Where do we store the instance of the memory manager for classes that do
> > need dynamic memory allocation? (per class or at the base class XMemory)
> >
> > Your comments and suggestions are appreciated.
> >
> > Khaled
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
> --
> /**********************************
> James D. Berry
> mailto:jberry@criticalpath.com
> vox:503.265.1213 fax:503.222.3020
> **********************************/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Configurable Memory Manager
Posted by James Berry <jb...@criticalpath.com>.
Khaled,
Watching your checkins for the memory manager changes, I'm somewhat shocked
by the changes required, and by the degree to which it seems this memory
manager needs to be passed around, into routines, etc.
Is there a way to eliminate that passing around of the memory manager by
making a global that can be accessed through a static function (and perhaps
also providing static functions for allocate and delete?).
-jdb
On 4/9/03 12:30 PM, "Khaled Noaman" <kn...@ca.ibm.com> wrote:
> Hi everyone,
>
> We have a request for a configurable memory management at static
> initialization and parser instance level. I thought that I would post the
> requirement and proposed design to the mailing list to gather feedback.
>
> Requirement:
> -------------
> Configurable memory management at the static initialization and parser
> instance level. This means all memory a parser might allocate directly
> or indirectly would come from a user supplied heap. When doing static
> initialization, users can supply a heap, which can be used for all static
> initialization as well as for memory allocation by static functions. This
> will allow users to control memory allocated for static instances as well
> as by static methods. A memory manager, per parser instance model
> ensures that if a parser leaks while parsing a document, we can just
> delete it and throw away the heap. This feature will make Xerces-C++
> more robust.
>
> Design Assumptions:
> ---------------------
> 1. The pluggable memory manager for static initialization will be set only
> once during the initialization for Xerces-C++
> 2. The external application owns the memory manager.
> 3. The external application is responsible for the thread safety of the
> memory allocation and deallocation.
> 4. Immutable memory manager/parser instance
> (i.e. no re-specification of memory managers on parsers)
>
> Design Overview:
> ------------------
> 1. Provide a memory manager interface that external applications can
> implement
> 2. Provide a default implementation that will be used if application do
> not provide their own memory manager.
> 3. Allow for setting application's memory manager during static initialization
> 4. Allow applications to plug-in their own memory managers per parser
> instance level.
> 5. Override class specific operator new and delete
> 6. Hold instance of memory manager in classes that need to allocate
> dynamic memory.
> 7. Other considerations
>
> Design Details:
> --------------
> 1. Memory manager interface
>
> class MemoryManager
> {
> public:
> virtual ~MemoryManager() {}
>
> virtual void* allocate(size_t size) = 0;
> virtual void deallocate(void* p) = 0;
>
> protected :
> MemoryManager() {}
>
> private:
> MemoryManager(const MemoryManager&);
> MemoryManager& operator=(const MemoryManager&);
> };
>
> 2. Default implementation
>
> class MemoryManagerImpl : public MemoryManager
> {
> public:
>
> MemoryManagerImpl() {}
> virtual ~MemoryManagerImpl() {}
>
> virtual void* allocate(size_t size);
> virtual void deallocate(void* p);
> private:
> MemoryManagerImpl(const MemoryManagerImpl&);
> MemoryManagerImpl& operator=(const MemoryManagerImpl&);
> };
>
> void* MemoryManagerImpl::allocate(size_t size)
> {
> return ::operator new(size);
> }
>
> void MemoryManagerImpl::deallocate(void* p)
> {
> ::operator delete(p);
> }
>
> 3. Xerces-C++ initiliazation
>
> MemoryManager* XMLPlatformUtils::fgMemoryManager = 0;
> bool XMLPlatformUtils::fgMemMgrAdopted = true;
>
> void XMLPlatformUtils::Initialize(const char* const
> locale
> , const
> char* const nlsHome
> ,
> PanicHandler* const panicHandler
> ,
> MemoryManager* const memMgr)
> {
> //
> // Effects of overflow:
> // . resouce re-allocations
> // . consequently resource leaks
> // . potentially terminate() may never get executed
> //
> // We got to prevent overflow from happening.
> // no error or exception
> //
> if (gInitFlag == LONG_MAX)
> return;
>
> // Set pluggable memory manager
> if (!fgMemoryManager) {
> if (memMgr) {
> fgMemoryManager = memMgr;
> fgMemMgrAdopted = false;
> }
> else {
> fgMemoryManager = new MemoryManagerImpl();
> }
> }
> ....
> ....
> }
>
> void XMLPlatformUtils::Terminate()
> {
> ....
> ....
>
> if (fgMemMgrAdopted)
> delete fgMemoryManager;
> else
> fgMemMgrAdopted = true;
>
> // And say we are no longer initialized
> gInitFlag = 0;
> }
>
> 4. Memory manager per parser instance
>
> Part of it is achieved in point 6. For other parsers that are not
> created directly,
> we modify the factory methods to take the manager as a parameter.
>
> e.g. // SAX2
> createXMLReader
> (
> MemoryManger* memMgr = XMLPlatformUtils::fgMemoryManager
> );
>
> 5. Override class specific new/delete operators.
>
> Introduce a new class, let's call it XMemory, that overrides C++ operator
> new and delete, and have that class be the base of many of Xerces-C++
> classes.
>
> class XMemory
> {
> public :
> void* operator new(size_t size);
> void* operator new(size_t size, MemoryManager* memMgr);
> void operator delete(void* p);
> void operator delete(void* p, MemoryManager* memMgr);
>
> protected :
> XMemory() {}
>
> private:
> XMemory(const XMemory&);
> XMemory& operator=(const XMemory&);
> };
>
> void* XMemory::operator new(size_t size)
> {
> void* const block = XMLPlatformUtils::fgMemoryManager->allocate
> (
> size + sizeof(MemoryManager*)
> );
>
> *(MemoryManager**)block = XMLPlatformUtils::fgMemoryManager;
>
> return (char*)block + sizeof(MemoryManager*);
> }
>
> void* XMemory::operator new(size_t size, MemoryManager* manager)
> {
> assert(manager != 0);
>
> void* const block = manager->allocate(size +
> sizeof(MemoryManager*));
> *(MemoryManager**)block = manager;
>
> return (char*)block + sizeof(MemoryManager*);
> }
>
> void XMemory::operator delete(void* p)
> {
> if (p != 0)
> {
> void* const block = (char*)p - sizeof(MemoryManager*);
>
> MemoryManager* const manager = *(MemoryManager**)block;
> assert(manager != 0);
> manager->deallocate(block);
> }
> }
>
> void XMemory::operator delete(void* p, MemoryManager* memMgr)
> {
> assert(p != 0 && manager != 0);
> assert
> (
> *(XercesMemoryManager**)((char*)p -
> sizeof(XercesMemoryManager*))
> == manager
> );
>
> manager->deallocate((char*)p - sizeof(XercesMemoryManager*));
> }
>
> 6. Hold instance of memory manager
>
> Modify constructors of Xerces-C++ classes to add a memory manager that
> is defaulted to the static instance.
> e.g.
> XMLScanner
> (
> XMLValidator* const valToAdopt
> , MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
> );
>
> 7. Other considerations
>
> For all calls to operator new [] and delete[], use the memory manager to
> allocate/deallocate the memory
> e.g.
> XMLCh* name = new XMLCh[10];
> --> XMLCh* name = memMgr->allocate(10 * sizeof(XMLCh));
>
> delete [] name; --> memMgr->deallocate(name);
>
> Modify DOMImplementation factory methods to pass in the memory manager
> e.g.
> createDocument
> (
> MemoryManager* memMgr = XMLPlatformUtils::fgMemoryManager
> );
>
> Some open Questions:
> -----------------------
> * Where do we store the instance of the memory manager for classes that do
> need dynamic memory allocation? (per class or at the base class XMemory)
>
> Your comments and suggestions are appreciated.
>
> Khaled
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
/**********************************
James D. Berry
mailto:jberry@criticalpath.com
vox:503.265.1213 fax:503.222.3020
**********************************/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Configurable Memory Manager
Posted by Khaled Noaman <kn...@ca.ibm.com>.
Hi Gareth,
I am for storing the memory manager at the class level (i.e. storage
on demand). It means that classes will only store the memory manager
if they need to. If we store the memory manager instance at the XMemory
class level, it means that every class inheriting from XMemory will have a
memory manager data member even if it does not need it. We could also
run into the problem of multiple inheritance where two or more copies of
the memory manager are inherited, and in that case we have to use virtual
inheritance.
Khaled
Gareth Reakes wrote:
> Hi Khaled,
> all sounds good to me. This will definitely help Pathan with
> robustness as well. I like the idea.
>
> > Some open Questions:
> > -----------------------
> > * Where do we store the instance of the memory manager for classes that do
> > need dynamic memory allocation? (per class or at the base class XMemory)
> >
>
> >From my point of view I would like to have to make the minimum number of
> changes in Pathan (and I expect this is a consideration for others who
> extend xerces as opposed to just use the interfaces). Do you feel that one
> of these approaches would require more changes to each sub class than the
> other?
>
> Gareth
>
> --
> Gareth Reakes, Head of Product Development +44-1865-203192
> DecisionSoft Limited http://www.decisionsoft.com
> XML Development and Services
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Configurable Memory Manager
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hi Khaled,
all sounds good to me. This will definitely help Pathan with
robustness as well. I like the idea.
> Some open Questions:
> -----------------------
> * Where do we store the instance of the memory manager for classes that do
> need dynamic memory allocation? (per class or at the base class XMemory)
>
>From my point of view I would like to have to make the minimum number of
changes in Pathan (and I expect this is a consideration for others who
extend xerces as opposed to just use the interfaces). Do you feel that one
of these approaches would require more changes to each sub class than the
other?
Gareth
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org