[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] adding wrapper functions for new and, delete operator

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] adding wrapper functions for new and, delete operators
Date: Fri, 11 Feb 2011 08:15:39 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As Bradley Jarvis wrote:

> I have had a look at gcc for the i686 and new and delete functions
> appear to be located in the library libstdc++ .

Yes, but this one, we don't have -- that's why we need the workaround
at all.  Btw, "new" and "delete" are language keywords (operators) in
C++, so they are *not* plain functions.

> There is an additional
> include directory called 'g++-v4' as well which contains the c++ header
> files and where the file 'new' is located which contains the declaration
> for new and delete (ie #include <new> is used to be able to use new and
> delete).

Due to the above, you don't need any include file in C++, they are
always "on board".  Example:

address@hidden 230% cat foo.C
#include <iostream>

   char *x = new char [5];
   x[0] = 'H';
   x[1] = 'i';
   x[2] = '\n';
   x[3] = 0;

   std::cout << x;

   return 0;
address@hidden 231% c++ -O -o foo -Wall -Wextra foo.C
address@hidden 232% ./foo

Note there are no warnings, despite there's no header file included
that would declare anything like "new".  Even though the C++ standard
has a <new> header file, this is not needed in order to use the "new"

> So I can look at adding the extra library libstdc++ for the code and
> the extra header file new.

Of course, it would be ultimately better to look into what's needed to
get libstdc++ really to compile.  That would solve us some other bugs
as well, and it could probably even add exceptions (though they are
*very* expensive, you typically wouldn't want to use them on devices
with less than 128 KiB of flash ROM).

However, by now, we'd just go ahead, and add the workarounds to some
avr-libc header file.  No extra library is needed, as the header file
will eventually redirect them to malloc/free which are already part of
the base avr-libc library.

> I would avoid using a header
> the header compat/c++.h since that would require the programmer to use a
> #ifdef to switch header files includes if the code is used on different
> platforms.

Then please suggest a better name ... I'm half-fine with naming it
just "new", though then make sure that it contains everything that is
mandated by the C++ standard.  I'm only half-fine with it because it's
normally GCC's business to install that file, so once G++ has been
fixed to include real libstdc++ support, this our file will eventually
collide with the correct one.  That's why I would be more happy with a
file name like compat/c++.h: it makes it more obvious to the user that
this is *not* the "real thing" but a workaround, which perhaps might
need special care (like, it's always being a "nothrow" implementation,
for example).

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]