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 at sdesigns dot com
- Subject: Re: [ECOS] Inside eCos : the new operator
- From: Bart Veer <bartv at redhat dot com>
- Date: Mon, 21 Aug 2000 14:32:39 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- References: <21DDE8E5343ED411840A00A0CC334020104850@exchange.sdesigns.com>
- Reply-to: bartv at redhat dot com
>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:
Fabrice> While trying to find answers to some of my questions I came accross this
Fabrice> code:
Fabrice> (in kernel/current/src/common/kapi.cxx. line ~370)
Fabrice> Cyg_Interrupt *t = new((void *)intr) Cyg_Interrupt (
Fabrice> (cyg_vector)vector,
Fabrice> (cyg_priority)priority,
Fabrice> (CYG_ADDRWORD)data,
Fabrice> (cyg_ISR *)isr,
Fabrice> (cyg_DSR *)dsr );
Fabrice> t=t;
Fabrice> CYG_CHECK_DATA_PTR( handle, "Bad handle pointer" );
Fabrice> *handle = (cyg_handle_t)intr;
Fabrice> The "t=t;" line is the most surprising to me but the
Fabrice> syntax of the new operator seems very interresting too.
Fabrice> I'm wondering what is the behaviour of the new operator
Fabrice> in a C++ eCos program? Can it do dynamic allocation? What
Fabrice> will happen in the above 'new' call if intr is a Null
Fabrice> pointer? Does the gcc patch required to compile it
Fabrice> explain all that? Are the 't' variable and the "t=t;'
Fabrice> line just a way to bluff the compiler?
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.
However it is possible to define alternative new operators which take
one or more arguments. In this case I believe that the intr argument
provides a suitable region of memory for the C++ object, and the
specific new() operator being used will just re-use this memory rather
than allocate a new chunk from the heap. For more details of placement
new, see e.g. Stroustrup 3rd edition and check the index (there is no
point in providing page numbers here, that book has gone through many
revisions already).
Passing a NULL pointer to new() would be a bad idea: you would be
explicitly telling the compiler that the interrupt object should be
placed at location 0, and it would probably do just that with
resulting nasty consequences.
The "t=t" line just stops the compiler from warning that the variable
t has been set but not used. The compiler will optimize this away. It
should be possible to write the code as:
(void) new((void*) intr) Cyg_Interrupt ( ... );
and do away with the t variable completely, but that code is even more
likely to confuse people.
I am not sure what gcc patch you are referring to.
Bart Veer // eCos net maintainer