This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Inside eCos : the new operator


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]