This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Inside eCos : the new operator
- To: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Subject: RE: [ECOS] Inside eCos : the new operator
- From: Robin Farine <advanc at dial dot eunet dot ch>
- Date: Tue, 22 Aug 2000 10:32:20 +0200 (CEST)
- cc: ecos-discuss at sourceware dot cygnus dot com
On Mon, 21 Aug 2000, Fabrice Gautier wrote:
> > -----Original Message-----
> > From: Bart Veer [mailto:bartv@redhat.com]
> > Subject: Re: [ECOS] Inside eCos : the new operator
> >
> > The invocation of the new() operator involves C++
> > placement syntax,
> > which is just part of the standard language.
> >
> > If the code looks something like:
> >
> > Object* ptr = new Object(arg1, arg2);
> >
> > then this invokes the default new operator, which will perform dynamic
> > memory allocation - I suspect it would end up calling malloc(), but
> > have not checked this.
>
> In this case, I suspect this will fail if the libc is not compiled as a part
> of eCos. In another message you mentionned the fact that eCos was not
> written with dynamic allocation in mind so I wonder how it handle a
> "dynamic" new operator. Does/Can it uses memory pools?
>
> > [...]
> > I am not sure what gcc patch you are referring to.
>
> The one I had to apply when building the gnu toolchain for eCos (as refered
> in the eCos installation documentation)
>
> Thanks
>
> --
> Fabrice Gautier
> fabrice_gautier@sdesigns.com
>
Fabrice,
The gcc distribution provides default implementations (libgcc) for the
different flavors of the "new" and "delete" operators. They rely on
malloc/free to obtain/release system memory regions.
However, in C++ you can overload any operator or function so you could do
something like this to avoid using the default implementation:
define a header file, "my_new.h" for instance, that redefines the
standard flavors of the new and delete operators:
/* ------------------------------------------------------------------- */
inline void* operator new (size_t size)
{
return my_allocate(size);
}
inline void* operator new[] (size_t size)
{
return ::operator new(size);
}
inline void* operator new (size_t, void* addr)
{
return addr;
}
inline void* operator new[] (size_t, void* addr)
{
return addr;
}
inline void operator delete (void* p)
{
my_deallocate(p);
}
inline void operator delete[] (void* p)
{
::operator delete(p);
}
/* ------------------------------------------------------------------- */
where "my_allocate()" and "my_deallocate()" handle the real job.
Then, include "my_new.h" instead of the standard "new.h" or "new" header
files. Alternatively, you could define custom "new" and "new.h" header
files in a directory that CPP includes from before its private headers
(specified using the -I CPP option).
Note also that you can define other version of those operators with
additional arguments, possibly dummy, such as:
inline void* operator new (size_t size, MemPartition* mp)
{
return mp_allocate(mp, size);
}
and use it like this:
Class_A* a = new(an_mp) Class_A(args);
where an_mp has type MemPartition*.
Or you can define class member versions that handle
allocation/deallocation of instances of that or derived classes, but this
becomes a bit more complex ... See
Working Paper for Draft Proposed International Standard for Information
Systems Programming Language C++
for a complete reference.
Hope this helps,
Robin