clamage@Eng.sun.com (Steve Clamage) writes:

>The strstream functions must use the global operator
>new and operator delete. Appendix D of the draft standard makes this clear.

Ah yes, right you are.  My earlier post stating that the standard didn't
say anything about strstream was wrong.  (Silly me, I didn't think that
deprecated features would be in the Annex titled "Future Directions"!
I guess I'll know to look harder next time ;-)

One more point though: the example program overloaded only `operator new'
and `operator delete'; it did not overload the array forms `operator new []'
and `operator delete []'.  Although the draft standard says that the
default behaviour of `operator new [] (size_t size)' is just to call
`operator new(size)', it does *not* say that the default behaviour of
`operator delete[] (void *p)' is to call `operator delete (p)'.
Instead it just says that it "reclaims [the] storage", without
specifying how.  [See 18.4.2.1.]  From this I conclude that it is
unspecified whether or not the replacement `operator delete' function
in the example program would get called.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3


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

>>>>> Alfredo V Mendoza <avm@zilker.net> writes:

> I have searched different C++ references and standards books but
> I could not find anything that will tell/show how overloading
> new and delete globally should be implemented. Hence I cannot
> show IBM that their implementation  is wrong.

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

In article 7351@mulga.cs.mu.OZ.AU, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>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().

strstreams are in Appendix D, deprecated features, but still part of
the standard. The description of the overflow function in D3.1.3 says
it must evaluate the expression
 new charT[n]
to allocate space, which means calling the global "operator new[]()".

---
Steve Clamage, stephen.clamage@eng.sun.com




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