This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: #include <new> in mqueue.cxx
- From: Martin Buck <martin dot buck at ascom dot ch>
- To: ecos-discuss at sources dot redhat dot com
- Date: Mon, 15 Jul 2002 14:31:23 +0200
- Subject: Re: [ECOS] #include <new> in mqueue.cxx
- Newsgroups: local.ecos.discuss
- Organization: Ascom Systec AG
- References: <C8B3DE2A53035248921C3DE1111FA503D77E@TITAN.protec.distefora.lan>
"Jones, Michael" wrote:
> I have tried the verious enviroment setting to make the compliler search a include path containing a "new" header. But so far without success.
You have to install libsupc++ as well - it provides the basic C++
infrastructure and <new> is a part of that.
> Also, I am not quite sure if I agree with the statement that the "new" header belongs to the compiler and therefore can be used.
> Afterall, the library has to "backup" the headerfiles - And the "new" header is based on a library that is not being incuded in the final build...
But it should. gcc 3.x for C++ without libsupc++ is something like gcc
for C without libgcc - a few things might work, but you won't get very
far.
> And as mqueue.cxx seems to be the only file that requires the "new" header - why does it require it? Why not change mqueue.cxx so that is does not require a header that no other files requires??
Have you considered that no other file might need that functionality,
but because it's ISO C++, it's perfectly reasonable to use if it *is*
needed?
While we're at it, some other files actually need that functionality
(placement operator new, e.g. in kapi.cxx), but they define their own
operator new instead. According to ISO C++ 18.4.1.3 clause 1 this is
illegal. Comments?
Martin
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss