🚀 go-pugleaf

>>>>> "JK" == James Kanze US/ESC 60/3/141 #40763 
      <kanze@lts.sel.alcatel.de> writes:
JK> In article <xsod973w4m5.fsf@glob.cs.rpi.edu> vandevod@cs.rpi.edu
JK> (David Vandevoorde) writes:
[...]
JK> |> Since you can provide your own new operators etc., you can ensure that
JK> |> it's safe to use realloc with new/delete (or you can provide a function
JK> |> based on realloc with similar functionality).
[...]
JK> 1. It is, in fact, impossible to obtain the address actually returned
JK> by operator new[].  The implementation is allowed to (and most do) ask
JK> for extra memory in order to maintain the number of elements.
JK> Typically, this memory will be in front of the first element, so the
JK> compiler will `fix up' the address returned by operator new[] before
JK> you ever see it.

I was aware of that... which is why I didn't claim it was portable :^P
and suggested ``a function with similar functionality''.

JK> 2. The implementation is allowed to save this address in some sort of
JK> cache.  For example, an alternate implementation of a new expression
JK> for an array would be for the implementation to maintain an
JK> associative array of addresses to counts.

That's more troublesome ;-)

	Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]