This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
AW: #include <new> in mqueue.cxx
- From: "Jones, Michael" <Michael dot Jones at distefora-protec dot de>
- To: "Martin Buck" <martin dot buck at ascom dot ch>,<ecos-discuss at sources dot redhat dot com>
- Date: Mon, 15 Jul 2002 16:58:29 +0200
- Subject: AW: [ECOS] #include <new> in mqueue.cxx
Hello!
Thanks for you response!
You are suggesting to install "libsupc++" - OK, but where to (and how)? And how do I tell the compiler where to find it?
And again why is it not part of the eCos repository?? The idea of such is to provide a working environment - I can hardly imagine that it relies on components that "maybe" exist on the build system. Or if yes, it should be documented somewhere...
As to your last two comments; I have at length considered the need for this construction and as bad style the usage is that we find in e.g. in kapi.cxx (yes - not nice is it?) the question is if somebody did it for a reason in the first place - like not having to rely on the new header?
Yet, as ever my primary target id to actually build a working app with eCos - and that is currently prohibited with this error (and I don't) seem to be the only. I will take whatever works in the long run, so I will be more then thankful for any advice that gets me there...
Regards,
Michael
> -----Ursprüngliche Nachricht-----
> Von: Martin Buck [mailto:martin.buck@ascom.ch]
> Gesendet: Montag, 15. Juli 2002 14:31
> An: ecos-discuss@sources.redhat.com
> Betreff: Re: [ECOS] #include <new> in mqueue.cxx
>
>
> "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
>
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss