Article View: comp.std.c++
Article #2191Re: overloading global new and delete
From: Fergus Henderson
Date: Sat, 14 Oct 1995 15:57
Date: Sat, 14 Oct 1995 15:57
63 lines
3296 bytes
3296 bytes
avm@zilker.net (Alfredo V. Mendoza) writes:
>The program below was a testcase sent to IBM compiler defect group.
>The problem is when compiled with IBM (413) xlC 3.1.2 , and ran
>the result is that the str() function in ostrstream does NOT use
>the overloaded new but uses the IBM runtime new. And when the class
>is destroyed the memory that was allocated by str() is deleted by the
>user defined global delete. Which (IMHO) is wrong.
The `ostrstream' class is not part of the draft C++ standard.
The old `char *' based strstream classes have been replaced by
a new set of `string' based stringstream classes.
So I'm afraid the draft C++ standard doesn't say anything about
about the behaviour of ostrstream::str().
Incidentally, the global operator new in your example was not
strictly conforming C++.
>// overload global new
>//
>void* operator new(size_t size)
>{
> void *p = malloc(size+sizeof(unsigned long));
>
> unsigned long *p1 = (unsigned long*)p; // get pointer to signpost
> *p1 = 0xdeadbeef; // set the signpost
> p1++; // set to start of user memory
> cout << "new(" << size << ") : signpost = " << (void*)p
> << " : user = " << (void*)p1 << endl;
> return((void*)p1);
>}
There is no guarantee that `p1' is suitably aligned here.
For example, this operator new will probably fail if you use it to
allocate a `double' on a SPARC, where doubles must be aligned
to 8-byte boundaries, but sizeof(long) == 4.
Another tricky issue is using `cout' in your global operator new.
Imagine what could happen if `ostream::operator<<' called your operator new:
your `::operator new' would call `ostream::operator<<', which could call
your `::operator new', which would call `ostream::operator<<', and so
on ... until stack overflow.
I think the current draft leaves it unspecified as to whether or not
library functions will call a user-defined global operator new.
>IBM compiler development claims that when one uses their runtime
>classes, it will always use the IBM runtime new and delete regardless
>of an overloaded global new and delete.
I imagine that one reason they do that is precisely to avoid the
problem of infinite recursion described above.
--
Fergus Henderson | "Australia is the richest country in the world,
fjh@cs.mu.oz.au | according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh | announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 | - Melbourne newspaper "The Age", 18 Sept 1995.
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<9528716.7351@mulga.cs.mu.OZ.AU>Path:
arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamageReferences:
<45js9r$iuq@hackberry.zilker.net>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamage From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Newsgroups: comp.std.c++ Subject: Re: overloading global new and delete Date: 14 Oct 1995 15:57:24 GMT Organization: Computer Science, University of Melbourne, Australia Sender: news@cs.mu.OZ.AU (CS-Usenet) Approved: clamage@eng.sun.com (comp.std.c++) Message-ID: <9528716.7351@mulga.cs.mu.OZ.AU> References: <45js9r$iuq@hackberry.zilker.net> NNTP-Posting-Host: taumet.eng.sun.com Originator: clamage@taumet