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: Tue, 22 Aug 2000 11:15:43 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- References: <8AE4B526B977D411841F00A0CC334020052C19@cuz-exchange.sdesigns.net>
- Reply-to: bartv at redhat dot com
>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:
>> -----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.
Fabrice> In this case, I suspect this will fail if the libc is not
Fabrice> compiled as a part of eCos. In another message you
Fabrice> mentionned the fact that eCos was not written with
Fabrice> dynamic allocation in mind so I wonder how it handle a
Fabrice> "dynamic" new operator. Does/Can it uses memory pools?
Internally the kernel does not use this default invocation of the new
operator, so it never gets linked in and there is never any need for
malloc().
If application code starts to use the default new operator then you
would have to ensure that a suitable one is available. This could mean
writing your own, or providing your own malloc(), or enabling the C
library package.
Bart Veer // eCos net maintainer