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()" functionin C. Thanks a lot


Eric Donnat wrote:
On 30 Jul 2003 11:43:53 +0100 Nick Garnett <nickg@ecoscentric.com>
wrote:
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.

I guess you are alluding to the I/O synchronisation requirements. Yes, that used to be true, but libstdc++ is now based on top of stdio and synchronises itself with that. This can sometimes be overkill and so there's a libstdc++ function to disable that.

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).

I suppose I'll say as usual that I've got exceptions working here (or used to anyway ;-)... old code base), but a final effort is needed to clean it up and contribute it, but enough of an effort that it probably ain't gonna happen till someone asks for it.


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.

I think there has to be a certain amount of emphasis on running libstdc++'s own tests rather than trying to guess whether it's implemented right or testing yourself.


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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