Matt Austern writes:
> __type_traits is part of our STL implementation.  And, in fact, it's
> what I was referring to when I said that at least one compiler has
> hooks so that you can tell if a type is a POD.  The compiler I was
> thinking of is SGI MIPSPro 7.2.

The SGI approach improves performance on container classes whose
elements are PODs, but one can go further than this.

> (And to give credit even more precisely: Alex Stepanov explained why
> something like __type_traits would be useful for the STL, and Michey
> Mehta modified the compiler to support it.  Joe Buck (not at SGI)
> independently proposed a similar mechanism.)

My proposal (not a standards change, just an implementation mechanism)
was concerned with speeding the relocation operation for vectors of
objects that can be correctly relocated with only a shallow copy.
A very large number of classes have this property (the STL containers
as implemented by SGI, as well as rope<> and most basic_string<>
implementations do as well).

One way to do this is to extend the __type_traits mechanism; another more
general approach is to add a new standard algorithm relocate() which is
much like swap() and that can be specialized on a per-class basis.
(Publishing standards for relocate would be a standards extension, but
vendors could provide __relocate, say).

Note that STL implementers are free to make, for example,
vector<vector<T>> or vector<string> a vastly more efficient class
by doing this -- the "top" vector can be relocated and extended without
copying the "child" vectors or mucking with the reference counts
of the strings (just do a shallow copy).  This would be done by
doing all relocation with a __relocate method that can be specialized.


--
-- Joe Buck
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <34B2CB3C.7F3E@pratique.fr>, bonnardv@pratique.fr
(Valentin Bonnard) wrote:

> I agree with Bjarnes that realloc is ugly and low level

Oh, is C++ abandoning low-level programming to C?

> Thus the vector<> would do the rigth think, and would be
> very efficient.

Nice if true!  We shall have to wait and see.

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

Matt Austern <austern@sgi.com> writes:

> kanze@gabi-soft.fr (J. Kanze) writes:
>
> > |>  So, can I please enter a plea for a C++ realloc function that
> > |>  does work with new[] and delete[] and that can be overridden as
> > |>  new[] and delete[] can?

No ! (others may disagree)

I thought (and hope) that there was pressure to ban (no, I
mean never enhance) C arrays in the commitee: is it an
illusion ? a dream ?

> > This has been discussed before here or in comp.std.c++.  Basically, the
> > problem is that there is no way of doing it other than simply allocate,
> > copy, free (which you can easily do yourself).  The C++ memory model is
> > more complex than that of C, and memory isn't just a bunch of bits that
> > can be copied.
>
> To be just slightly more precise: in general you can't do anything
> other than allocate, copy, and free, because *in general* memory isn't
> just a bunch of bits that can be memcopied..
>
> Sometimes memory is just a bunch of bits, though; the compiler has to
> know when that's the case, and at least one compiler provides hooks so
> that users (i.e. library implementors) can access that information
> too.

But the allocators don't have a reallocate () member.

I agree with Bjarnes that realloc is ugly and low level,
but allocators are low level too, and reallocation is
usefull for a vector<> implementation. Also std traits
types to know which types have a copy ctor, are PODs, ect...
would be usefull (they are in STLport, or is it SGI-STL ?).

Thus the vector<> would do the rigth think, and would be
very efficient.

I think it's very important to have a nearly perfect
vector<> class in order to argue against built-in arrays
and against auto_array<>.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

> > Sometimes memory is just a bunch of bits, though; the compiler has to
> > know when that's the case, and at least one compiler provides hooks so
> > that users (i.e. library implementors) can access that information
> > too.
>
> I agree with Bjarnes that realloc is ugly and low level,
> but allocators are low level too, and reallocation is
> usefull for a vector<> implementation. Also std traits
> types to know which types have a copy ctor, are PODs, ect...
> would be usefull (they are in STLport, or is it SGI-STL ?).

__type_traits is part of our STL implementation.  And, in fact, it's
what I was referring to when I said that at least one compiler has
hooks so that you can tell if a type is a POD.  The compiler I was
thinking of is SGI MIPSPro 7.2.

(And to give credit even more precisely: Alex Stepanov explained why
something like __type_traits would be useful for the STL, and Michey
Mehta modified the compiler to support it.  Joe Buck (not at SGI)
independently proposed a similar mechanism.)

I don't know of any other compilers that have those hooks; I hope that
other compiler vendors do add them, though, and I hope that they can
be added to a future revision of the C++ standard.  The __type_traits
mechanism does have some value even on compilers that don't have
built-in support for it, but it's much more useful with that support.

__type_traits and realloc are a useful combination; realloc alone is
less useful.
---
[ 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
]

In a message that didn't make it here Joe Buck allegedly wrote:

> An analog to realloc in C++ would need to call constructors
> and destructors properly.

I know this.  The 'operator realloc[]' I was talking about would
do this.  As for a C++ realloc function, I'd be quite happy to
live with the restriction that it only works with POD types
(maybe without the private members restriction).

> Fortunately, this has been done already.  It's called
> vector<T> -- it automatically reallocates its storage as
> needed when it grows.

Well, this cure might be worse than the disease itself.  After
all, I can always new[] a new array and copy to it myself.  The
whole point is that I'm talking about _large_ arrays in
intensively-used code.  If vector<T> doesn't use some realloc-
like magic it's going to be expensive and if it does I'd like
access to it myself.

What's more I'm not so concerned with growing as with shrinking.
I normally want to realloc when I've vastly overallocated an
array (to save on the copying as it grows) and now want to
shrink it to the required size.

In article <349AD827.340E2F98@ix.netcom.com> Paul D. DeRocco
<pderocco@ix.netcom.com> wrote:

> Another consideration is that with arrays, at least arrays of
> classes that have destructors, the pointer returned by "new
> T[n]" isn't usually the same as the pointer returned
> internally by "operator new[]". The compiler generally
> requests an extra four bytes or so at the beginning, for recor
> ding how many elements there are in the array for the benefit
> of operator delete[], so the "new T[n]" pointer is usually
> four bytes higher than the "operator new[]" pointer. Worse,
> the compiler may choose not to do this for types (e.g., char)
> that don't have destructors. Thus, any realloc function you
> write in C++ will have to be able to figure out whether or
> not to decrement the pointer before calling the underlying C
> realloc function.

Well, again an 'operator realloc[]' would know this.  With a
realloc function I'd be happy to be restricted to POD types or
types with no {con,de}structors.  I rarely use arrays of complex
objects and wouldn't mind being unable to realloc them.  It's
arrays of char and arrays of pointers that I typically want to
realloc.  The one guarantee I would like is that what has been
realloc'ed can be delete[]'ed.  (It's unreasonable to expect
client code to know when to delete[] and when to free.)  I'd
hope that the restrictions on the use of realloc would be enough
to allow for these possible differences in the representation of
new[]'ed arrays of different types.  Remember, I want realloc to
be provided by the implementor.  If I though I could write my
own I wouldn't be asking for a standard one.

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

H. Peter Anvin <hpa@transmeta.com> schrieb:
> There is a fundamental problem here, though: without the realloc
> operator, there is no hope of *ever* being able to avoid this very
> expensive operation.  Then there is the lost hope of being able to
> shuffle page tables rather than data around... I guess there is still
> use for malloc()...realloc()...free()...

Yes: for the implementation of vector<>. vector<> can use malloc(), =20
realloc() and free() for its memory management; sophisticated =20
implementations will have to, as they want to alloc more memory than =20
they need for the current number of objects (new calls constructors for =20
all objects for which it reserves memory).

The big difference between new/delete and malloc/realloc/free is that =20
new and delete work with objects, wheras the C mem management functions =20
work with raw memory.

--=20
Claus Andr=E9 F=E4rber <http://www.muc.de/~cfaerber/> Fax: +49_8061_3361
PGP: ID=3D1024/527CADCD FP=3D12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C=
9 DC
---
[ 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
]

On 29 Dec 97 03:46:34 GMT, jbdp@cix.compulink.co.uk ("Julian Pardoe")
wrote:

>In a message that didn't make it here Joe Buck allegedly wrote:
>
>> An analog to realloc in C++ would need to call constructors
>> and destructors properly.
>
>I know this.  The 'operator realloc[]' I was talking about would
>do this.  As for a C++ realloc function, I'd be quite happy to
>live with the restriction that it only works with POD types
>(maybe without the private members restriction).

You already have that capability for POD types: malloc, realloc, and
free.

>> Fortunately, this has been done already.  It's called
>> vector<T> -- it automatically reallocates its storage as
>> needed when it grows.
>
>Well, this cure might be worse than the disease itself.  After
>all, I can always new[] a new array and copy to it myself.  The
>whole point is that I'm talking about _large_ arrays in
>intensively-used code.  If vector<T> doesn't use some realloc-
>like magic it's going to be expensive and if it does I'd like
>access to it myself.

You are not assured that a given implementation of realloc will expand
an array in place. OTOH, the implementation of the vector template
might expand storage in place. In other words, it you can't
necessarily assume that realloc would be better than vector.

>What's more I'm not so concerned with growing as with shrinking.
>I normally want to realloc when I've vastly overallocated an
>array (to save on the copying as it grows) and now want to
>shrink it to the required size.

But you also have no assurance that realloc to a smaller size will in
fact reduce the amount allocated.

It sounds like you are depending of details of particular
implementations instead of on what the language definition promises.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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
]

claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=) writes:

|>  Yes: for the implementation of vector<>. vector<> can use malloc(),
|>  realloc() and free() for its memory management; sophisticated
|>  implementations will have to, as they want to alloc more memory than
|>  they need for the current number of objects (new calls constructors for
|>  all objects for which it reserves memory).

The usual solution for this (at least for me) has been to call the
operator new function, rather than malloc.

|>  The big difference between new/delete and malloc/realloc/free is that
|>  new and delete work with objects, wheras the C mem management functions
|>  work with raw memory.

The new and delete expressions work on objects.  To manage memory, they
call the operator new and operator delete functions, which manage raw
memory.  It is perfectly permissable to call these functions explicitly.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <34a97622.1599659@engnews1.eng>,
stephen.clamage_nospam@Eng.Sun.COM (Steve Clamage) wrote:

> You already have that capability for POD types:
> malloc, realloc, and free.

I know, but the problem is that it is too much to ask client
code to remember when to delete[] and when to free.  That's why
I want a realloc that is compatible with delete[] for char *
etc..

> You are not assured that a given implementation of realloc
> will expand an array in place. OTOH, the implementation of the
> vector template might expand storage in place. In other
> words, you can't necessarily assume that realloc would be
> better than vector. [...] You also have no assurance that
> realloc to a smaller size will in fact reduce the amount
> allocated.

All true, but it's not an unreasonable guess that realloc'ing to
a smaller size will often free up some memory.  Likewise it's
not an unreasonable guess that vector<char> will be less
efficient that new'ed char[]s for many applications.

Maybe I'm silly to be so concerned about wasted memory; the days
when one had to cram systems into 32K are generally gone.  (This
machine runs DOS though and I still prefer to use the small
model if I can get away with it.)  However a delete[]-compatible
realloc, say reallocate_array, for POD types isn't much to ask.
It should be easy to specify and easy to implement.  The
difficult bit would be getting it through the Committee...

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

Does the Standard say anything about the compatibility of C++'s new, new[]
etc. with malloc, free and realloc?  I meet this most often because I want
to realloc a buffer.  If I allocate a buffer using malloc/realloc and then
delete[] it am I safe under the Standard?  Having client code remember
whether to free or delete[] a buffer is too much to ask.  I always felt
that this was a problem in theory but recently I found that with at least
one compiler it is a problem in practice!  I can imagine that this might
be a problem when using C libraries: a client might be responsible for
freeing something allocated by a library.

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

Julian Pardoe wrote:

> Does the Standard say anything about the compatibility of C++'s new, new[]
> etc. with malloc, free and realloc?

I think it says that they are not compatible; that is, new pairs with
delete,
new[] pairs with delete[], and malloc pairs with free, and those are the
only pairs allowed.  We worked from that assumption when building a C++
debugging tool, and there were people on the team who know the standard
very well and would not have let me waste time on this if it were not
true.

> I meet this most often because I want
> to realloc a buffer.  If I allocate a buffer using malloc/realloc and then
> delete[] it am I safe under the Standard?

I think you are generally not safe, both according to the standard,
and also in practice.  One obvious way tfor a C++ implementation
to remember useful things about arrays (such as how many constructors
and destructors have been run) is to reserve a little space before
the beginning of the array.  If delete[] expects that space and you
got the memory from malloc, or if free does not expect that space
and you got the memory from new[], bad things can happen.  One
reason that I know this is that we encountered such an implementation
while working on the aforementioned C++ debugging tool, and these
offset pointers added a wee bit of hair to a runtime library that
was already pretty fuzzy.

> Having client code remember whether to free or delete[] a buffer
> is too much to ask.

Mandate one or the other, or provide a deletion function for the
client to call.  (Actually, I agree with you completely, which is
why I am such a big fan of garbage collection and languages which
support it properly.  But, this is a C++ newsgroup.)  There are
tools that will help you do this; C++Expert(*) is one example that
I know will spot this error.

(*) The marketing department of my former employer has recently
changed the name of the product to "AcquaProva", or so I am told
by people who seemed to have a straight (actually, somewhat pained)
face when they told me.  I wanted to call it C++Sanitizer, but no,
they never listen to those tasteless engineers.

> ... I can imagine that this might
> be a problem when using C libraries: a client might be responsible for
> freeing something allocated by a library.

C++ gives you control over memory allocation; it's up to the programmer
to do it right.  I'd like to say "garbage collection will cure your
problem" but unless you use a conservative collector, you will have many
of the same problems getting along with C no matter what you do.  But,
if you do use a conservative collector, it will work very well with
your C code.  C++ is a little bit more of a problem because it may
expect destructors to be run when memory is recycled, and that is not
guaranteed, and is surely not guaranteed to occur in a timely fashion.

--
David Chase, chase@world.std.com
---
[ 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
]

"Julian Pardoe" <jbdp@cix.compulink.co.uk> wrote in article
<ELCs9I.259@cix.compulink.co.uk>...
> Does the Standard say anything about the compatibility of C++'s new,
new[]
> etc. with malloc, free and realloc?  I meet this most often because I
want
> to realloc a buffer.  If I allocate a buffer using malloc/realloc and
then
> delete[] it am I safe under the Standard?  Having client code remember
> whether to free or delete[] a buffer is too much to ask.  I always felt
> that this was a problem in theory but recently I found that with at least

> one compiler it is a problem in practice!  I can imagine that this might
> be a problem when using C libraries: a client might be responsible for
> freeing something allocated by a library.

The relationship of new and malloc is deliberately unspecified, so
attempting to delete memory obtained from malloc is undefined behavior.
Even if the default operator new() were to call malloc() consider what
would happen if you wrote your own operator new() that didn't.

I find that in my own programs that I must deal with lots of different
allocators anyway, include new, malloc, and various system-specific
allocators, so I have my own smart pointer types for each allocator.

Greg Colvin
---
[ 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
]

On 17 Dec 1997 16:36:16 PST, jbdp@cix.compulink.co.uk ("Julian
Pardoe") wrote:

>Does the Standard say anything about the compatibility of C++'s new, new[]
>etc. with malloc, free and realloc?

Yes. The relationship of new and delete to malloc/calloc/realloc and
free is "unspecified". That means the standard neither requires nor
forbids any relationship, and the implementation doesn't have to tell
what the relationship is.

The only rule is that malloc/calloc/realloc cannot call operator new,
and free cannot call operator delete. That rule means you can always
implement your own versions of operator new and delete by calling
malloc and free if you wish.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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
]

In article <01bd0b72$54c64860$6dbd83cc@vagabond.imrgold>,
dont@spam.me (greg) wrote:

> The relationship of new and malloc is deliberately
> unspecified, so
> attempting to delete memory obtained from malloc is undefined
> behavior.
> Even if the default operator new() were to call malloc() consi
> der what
> would happen if you wrote your own operator new() that didn't.

Well, I'd pay the price!!  But usually I don't so the problem
doesn't arise.  I've thought about the design of an operator
realloc (), but really a standard C++ library function
compatible with the default global operator new () would be fine
and easy to specify.  If I wrote my own new () I could write my
own C++ global realloc -- it should replace the default one of
course, just as my new () replaces the default new ().

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> Yes. The relationship of new and delete to malloc/calloc/realloc and
> free is "unspecified". That means the standard neither requires nor
> forbids any relationship, and the implementation doesn't have to tell
> what the relationship is.

A shame; see my reply to Don T's message for an idea!

> The only rule is that malloc/calloc/realloc cannot call operator new,
> and free cannot call operator delete. That rule means you can always
> implement your own versions of operator new and delete by calling
> malloc and free if you wish.

Ah, well that's a solution to my problem  anyway.  Is there any
reason why doing so might be a bad idea?

-- jP --

PS: Why does no one ever answer my question about extern "C"
functions?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:
>Well, I'd pay the price!!  But usually I don't so the problem
>doesn't arise.  I've thought about the design of an operator
>realloc (), but really a standard C++ library function
>compatible with the default global operator new () would be fine
>and easy to specify.

An analog to realloc in C++ would need to call constructors and
destructors properly.  Fortunately, this has been done already.
It's called vector<T> -- it automatically reallocates its storage
as needed when it grows.
--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html
 If you thought flashing ads on Web sites were annoying, wait till the Web
 and your operating system are "seamlessly integrated" and watch the
 pulsating promotional crud spill out over your desktop.  -- Scott Rosenburg
---
[ 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
]

jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:

|>  > Yes. The relationship of new and delete to malloc/calloc/realloc and
|>  > free is "unspecified". That means the standard neither requires nor
|>  > forbids any relationship, and the implementation doesn't have to tell
|>  > what the relationship is.
|>
|>  A shame; see my reply to Don T's message for an idea!
|>
|>  > The only rule is that malloc/calloc/realloc cannot call operator new,
|>  > and free cannot call operator delete. That rule means you can always
|>  > implement your own versions of operator new and delete by calling
|>  > malloc and free if you wish.
|>
|>  Ah, well that's a solution to my problem  anyway.  Is there any
|>  reason why doing so might be a bad idea?

Well, you do preempt any one else's doing so, say for debugging
purposes.  Replacing the global operator new and delete should generally
be an operation only allowed to those doing the final integration.

In addition, if your idea is that by doing so, you can mix malloc/free
and new/delete in your code, it won't work anyway.  The pointer you
return from operator new[] is NOT necessarily the pointer you see in
your code.  When you invoke a new[] expression, the compiler is free the
add whatever it wishes to the amount of memory it requests, and the
pointer returned by the new[] expression is NOT necessarily the same
address as the one returned by the operator new[] function.  (This isn't
just theoretic -- it's the actual case for many compilers.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <m3yb1fy7rd.fsf@gabi-soft.fr>, kanze@gabi-soft.fr (J.
Kanze) wrote:

> jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:
>
> > Is there any reason why [replacing global new/delete] might
> > be a bad idea?
>
> Well, you do preempt any one else's doing so, say for
> debugging purposes.  Replacing the global operator new
> and delete should generally be an operation only allowed to
> those doing the final integration.

Fair enough.  I was going to say myself that people might not
like it in libraries I supply to them.

> In addition, if your idea is that by doing so, you can mix mal
> loc/freeand new/delete in your code, it won't work anyway.
> The pointer you return from operator new[] is NOT necessarily
> the pointer you see in your code.  When you invoke a new[]
> expression, the compiler is free the add whatever it wishes to
> the amount of memory it requests, and the pointer returned by
> the new[] expression is NOT necessarily the same address as
> the one returned by the operator new[] function.  (This isn't
> just theoretic -- it's the actual case for many compilers.)

I was wondering about this too.  I imagined it was what bit me
when I was using Sun C++.

So, can I please enter a plea for a C++ realloc function that
does work with new[] and delete[] and that can be overridden as
new[] and delete[] can?

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Julian Pardoe wrote:
>
> So, can I please enter a plea for a C++ realloc function that
> does work with new[] and delete[] and that can be overridden as
> new[] and delete[] can?

In C++, reallocation is an intrinsically high-level concept. This is because
reallocation, if the array is being enlarged, may entail moving the existing
data to a new location. Doing so involves copy construction of each element
from the old location to the new location, and then destroying the old one.
This is probably too much to ask for a simple operator built into the language.
It is, however, exactly what vector<T> does, so you might as well just use
vector<T> instead.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Joe Buck wrote:
>
> jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:
> >Well, I'd pay the price!!  But usually I don't so the problem
> >doesn't arise.  I've thought about the design of an operator
> >realloc (), but really a standard C++ library function
> >compatible with the default global operator new () would be fine
> >and easy to specify.
>
> An analog to realloc in C++ would need to call constructors and
> destructors properly.  Fortunately, this has been done already.
> It's called vector<T> -- it automatically reallocates its storage
> as needed when it grows.

Another consideration is that with arrays, at least arrays of classes that have
destructors, the pointer returned by "new T[n]" isn't usually the same as the
pointer returned internally by "operator new[]". The compiler generally
requests an extra four bytes or so at the beginning, for recording how many
elements there are in the array for the benefit of operator delete[], so the
"new T[n]" pointer is usually four bytes higher than the "operator new[]"
pointer. Worse, the compiler may choose not to do this for types (e.g., char)
that don't have destructors. Thus, any realloc function you write in C++ will
have to be able to figure out whether or not to decrement the pointer before
calling the underlying C realloc function.

I agree: if you need to resize, use vector<T>.

--

Ciao,
Paul
---
[ 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
]

Julian Pardoe <jbdp@cix.compulink.co.uk> wrote:
> If I wrote my own new () I could write my
> own C++ global realloc -- it should replace the default one of
> course, just as my new () replaces the default new ().

Replacing operator new() is legal, but replacing realloc() is not.
Some implementations might allow it, but some implementations might
use malloc to implement operator new().

Often when you think you want realloc, you actually want vector<>.
Consider alternatives.

Nathan Myers
ncm@cantrip.org
---
[ 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
]

jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:

|>  Does the Standard say anything about the compatibility of C++'s new, new[]
|>  etc. with malloc, free and realloc?

Yes.  It says that malloc et al. will not be implemented in terms of new
et al.  This is mainly for people who replace the global new -- they can
use malloc for the actual memory management, and be guaranteed that they
won't get infinite recursion.

|>  I meet this most often because I want
|>  to realloc a buffer.  If I allocate a buffer using malloc/realloc and then
|>  delete[] it am I safe under the Standard?

No.

|>  Having client code remember
|>  whether to free or delete[] a buffer is too much to ask.  I always felt
|>  that this was a problem in theory but recently I found that with at least
|>  one compiler it is a problem in practice!  I can imagine that this might
|>  be a problem when using C libraries: a client might be responsible for
|>  freeing something allocated by a library.

This is a real problem, at least where C libraries are concerned.  (I
don't buy the realloc argument -- realloc doesn't work with constructors
anyway.)  The only solution is to encapsulate the memory management in a
class -- if need be, make a copy of the memory immediately, and then
free it.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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
]

Followup to:  <349D8316.546E5FF@ix.netcom.com>
By author:    "Paul D. DeRocco" <pderocco@ix.netcom.com>
In newsgroup: comp.std.c++
>
> Julian Pardoe wrote:
> >=20
> > So, can I please enter a plea for a C++ realloc function that
> > does work with new[] and delete[] and that can be overridden as
> > new[] and delete[] can?
>=20
> In C++, reallocation is an intrinsically high-level concept. This is
> because reallocation, if the array is being enlarged, may entail
> moving the existing data to a new location. Doing so involves copy
> construction of each element from the old location to the new
> location, and then destroying the old one.  This is probably too
> much to ask for a simple operator built into the language.  It is,
> however, exactly what vector<T> does, so you might as well just use
> vector<T> instead.
>=20

There is a fundamental problem here, though: without the realloc
operator, there is no hope of *ever* being able to avoid this very
expensive operation.  Then there is the lost hope of being able to
shuffle page tables rather than data around... I guess there is still
use for malloc()...realloc()...free()...

 -hpa

--=20
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah=E1'=ED -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Mis=E9rable=
s
---
[ 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
]

jbdp@cix.compulink.co.uk ("Julian Pardoe") writes:

|>  So, can I please enter a plea for a C++ realloc function that
|>  does work with new[] and delete[] and that can be overridden as
|>  new[] and delete[] can?

This has been discussed before here or in comp.std.c++.  Basically, the
problem is that there is no way of doing it other than simply allocate,
copy, free (which you can easily do yourself).  The C++ memory model is
more complex than that of C, and memory isn't just a bunch of bits that
can be copied.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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
]

kanze@gabi-soft.fr (J. Kanze) writes:

> |>  So, can I please enter a plea for a C++ realloc function that
> |>  does work with new[] and delete[] and that can be overridden as
> |>  new[] and delete[] can?
>
> This has been discussed before here or in comp.std.c++.  Basically, the
> problem is that there is no way of doing it other than simply allocate,
> copy, free (which you can easily do yourself).  The C++ memory model is
> more complex than that of C, and memory isn't just a bunch of bits that
> can be copied.

To be just slightly more precise: in general you can't do anything
other than allocate, copy, and free, because *in general* memory isn't
just a bunch of bits that can be memcopied..

Sometimes memory is just a bunch of bits, though; the compiler has to
know when that's the case, and at least one compiler provides hooks so
that users (i.e. library implementors) can access that information
too.
---
[ 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
]

H. Peter Anvin wrote in message <67m14u$m1p$1@palladium.transmeta.com>...

>There is a fundamental problem here, though: without the realloc
>operator, there is no hope of *ever* being able to avoid this very
>expensive operation [of reallocating and calling all the destructors
>and copy constructors].

But of course there is. That's exactly what the "reserve" method of all
sequential containers and strings is for. If you have some idea of the
amount of elements you need, you can tell the container in advance, and it
will only allocate once, without making copies. Furthermore, when the
container does need to reallocate, it's required to use a reallocation
pattern that is an amortized linear in number of allocations and copies,
better than typical, naively realloced buffers. The worst case is log N
allocations and N "unnecessary" copies.

>Then there is the lost hope of being able to
>shuffle page tables rather than data around... I guess there is still
>use for malloc()...realloc()...free()...


That sort of thing is what custom allocators are for. I agree with the
majority that vector<> is the replacement for realloc() and that realloc()
doesn't play well with constructors and destructors. However, since
allocators deal largely with uninitialized memory, perhaps C++200x could add
a realloc() type method to the allocator<> interface.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ 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
]

In article <fxten359jx3.fsf@isolde.mti.sgi.com>, austern@sgi.com
(Matt Austern) wrote:

> kanze@gabi-soft.fr (J. Kanze) writes:
> > This has been discussed before here or in comp.std.c++.
> > Basically, the problem is that there is no way of doing it
> > other than simply allocate, copy, free (which you can easily
> > do yourself).  The C++ memory model is more complex than
> > that of C, and memory isn't just a bunch of bits that
> > can be copied.

Yes, I can copy the data from malloc'ed memory to new[]'ed
memory, but at a cost in time.

> To be just slightly more precise: in general you can't do
> anything other than allocate, copy, and free, because
> *in general* memory isn't just a bunch of bits that can
> be memcopied..

Exactly.  I typically want realloc for non-class types and could
live with it not working for objects.

I did once start thinking about an 'operator realloc[]' but I
can't remember how far I got.  It would have destructed or
default-constructed objects as appropriate.  Operator delete[]
can destruct objects so I don't think a realloc[] would require
information that isn't available.

I requested a function because it was simpler and would have
satisfied the simple cases when I tend to want realloc.  I'd
hope C++ programmers would be intelligent enough to know when
they could use the 'realloc' function and when they couldn't.

There's a difference between something being impossible to
specify in way that will allow the range of hardware
architectures and implementation style that the Standard is
trying to accommodate and something being impossible to specify
in way that is "100% orthogonal" (in Algol 68 style).  Saying
that in general "memory isn't just a bunch of bits that can be
copied" sounds like an orthogonality argument to me.

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