This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Question about "new" operator in C++ and "malloc()"function in C. Thanks a lot
On 30 Jul 2003 11:43:53 +0100
Nick Garnett <nickg@ecoscentric.com> wrote:
> "QiangHuang" <jameshq@liverpool.ac.uk> writes:
>
> > Dear all:
> > I have this question in mind for a while and I still can't figure it
> > out. Hope somebody can share me some idea on this question. Thanks a lot.
> >
> > Question 1:
> > When using "new" operator in C++ for building eCOS application, no
> > supporting package is needed while for using "malloc()" function, supporting
> > package "memalloc" has to be added for building the eCOS library. Those two
> > are all for memory allocation, so I wonder why "new" doesn't need any other
> > supporting package while "malloc" does. (Can I guess the reason that: "new"
> > is a operator, which has been implemented by the C++ compiler while for
> > "malloc()" is a function, which will need lower level(system related)
> > function support (from some other library, stdlib?)? )
>
> If new is being used to allocate memory, then it needs exactly the
> same support as malloc(). It just calls malloc() to do the
> allocation. However, in some places in eCos we use a "placement new"
> where the memory to be used is passed in as an argument to new. This
> is done mainly so that constructors can get called correctly, there is
> no need for extra support.
>
> >
> > Question 2:
> > When compiling/linking a 'C' eCOS application "-nostdlib" need to be
> > suppiled, but if for 'C++' eCOS appliation do I need to supply any other
> > directive? Or "-nostdlib" is applied for both 'C' and "C++" built eCOS
> > appliation (Does this means we can just use C/C++ built in operator for
> > building eCOS appliation not any other supporting functions?)?
>
> We currently don't support any of the C++ runtime library routines. To
> do this properly would also need a reorganization of the C library to
> abstract out common code and preserve the expected relationships
> between functions. Only functions/operators that are defined as part
> of the language (like new and delete) are currently supported.
>
I agree with Nick, and my purpose here is just to point just how much implications
one must deal with, if one want some kind of real C++ new stuf. If you've got time,
just take your breath and travel inside the 'C++' ISO (well the draft, that is available freely
on the web).
You then may find some tricky things such as the basic
void *operator new(size_t size) { return my_alloc(size);}
is INVALID in C++ because returning a null pointer is UNSPECIFIED in the scope of the new
operator. So you just can't say the problem is 'AS IS'. Mostly a working C++ new needs
some support for exceptions, set_new_handler, unexpected exception handling, abnormal
termination, set_terminate and the likes.
While supc++.a that comes when you are compiling GCC, probably handle much of such
annoyances (Yes, I'm a C coder), I presume eCos is still laking from a review of the supc++.a
code in order to get the whole stuff working, with fully analysed requirements (in CDL ??),
with any weird code, and why not configurability (for ISO C++ sub-standard).
IMHO, this is a full C++ guru job (I'm not the right guy for that, sorry). Even decoding the
C++ standard is already a full daunting job.
My conclude: DO NOT open the pandora's box. Placement new operator are concise, well
understandable, without any nifty-grifty.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss