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]
Other format: [Raw text]

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


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