In article <330CD1B6.5244@mds.rmit.edu.au> Marcelo Cantos <marcelo@mds.rmit.edu.au> writes:
>A. Grant wrote:
>> Nobody ever proposed that renew[]
>> should be a substitute for a container class copy constructor or
>> for a container class "grow" member function.

>Then what would it be used for?

For changing the size of arrays allocated by new[].
---
[ 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 <ag129.1253.0010CD81@ucs.cam.ac.uk>, ag129@ucs.cam.ac.uk
says...

[ ... ]

> Who says renew[] has to use realloc()?  Maybe it could use realloc()
> only for types with bitwise copy semantics, and do other arrays
> with malloc/free.

Ultimately, it doesn't matter.  Changing the size of a memory
allocation is entirely possible, and the difference between using
malloc/free and using realloc is, at most, one of efficiency.  The
real problem arises AFTER you've changed the size of the memory block,
particularly if you have to allocate a new block.  In this case you've
got to, somehow, get objects out of the old block and into the new
block.  Given the variety of objects, the variety of methods needed to
copy them reasonably, the number that use their own address as an
identity, etc., I doubt that there's a method of doing this that can
work reliably.

--
    Later,
    Jerry.
---
[ 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 <MPLANET.33014bf3jcoffin9896be@news.rmi.net> jcoffin@taeus.com (Jerry Coffin) writes:
>particularly if you have to allocate a new block.  In this case you've
>got to, somehow, get objects out of the old block and into the new
>block.  Given the variety of objects, the variety of methods needed to

Call the copy constructor on the new objects and the destructor
on the old objects.  If they happen to be at the same place,
don't call anything.  No need for special "move" semantics.

Did anyone actually _say_ renew[] couldn't call any destructors
when increasing the size of the array?
---
[ 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 <ag129.1272.0015CA45@ucs.cam.ac.uk>, ag129@ucs.cam.ac.uk (A.
Grant) writes:
|>
|> Call the copy constructor on the new objects and the destructor
|> on the old objects.  If they happen to be at the same place,
|> don't call anything.  No need for special "move" semantics.

This will break a great many things.

What happens if the objects being moved point to one another within the
container?  They will now all be pointing to the old locations,not the
new.

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.
---
[ 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 <5ea67k$mq5@rap.SanDiegoCA.NCR.COM> swf@elsegundoca.ncr.com (Stan Friesen) writes:
>|> Call the copy constructor on the new objects and the destructor
>|> on the old objects.  If they happen to be at the same place,
>|> don't call anything.  No need for special "move" semantics.

>This will break a great many things.

It will break nothing that doesn't use it.  It won't necessarily
break anything that does use it.  All that is needed is to be aware
of the implications of using it.

>What happens if the objects being moved point to one another within the
>container?  They will now all be pointing to the old locations,not the
>new.

Yes, just like with the old realloc().  If you realloc() an array
of structures containing pointers that point within the array,
it breaks.  Or if you realloc() an array some of whose elements
are pointed to from outside.  Nobody ever proposed that renew[]
should be a substitute for a container class copy constructor or
for a container class "grow" member function.
---
[ 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
]

A. Grant wrote:
> Yes, just like with the old realloc().  If you realloc() an array
> of structures containing pointers that point within the array,
> it breaks.  Or if you realloc() an array some of whose elements
> are pointed to from outside.  Nobody ever proposed that renew[]
> should be a substitute for a container class copy constructor or
> for a container class "grow" member function.

Then what would it be used for?


--
___________________________________________________________________
Marcelo Cantos, Research Assistant          marcelo@mds.rmit.edu.au
Multimedia Database Systems Group    __/_      _ Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
                                     /
---
[ 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
]

John Lilley <jlilley@empathy.com> writes:

>Fergus Henderson wrote:
>
>> But to make it really useful, you'd need a standard `move' function,
>> combining construction of the target and destruction of the source,
>> which could be specialized to do shallow copying rather than deep
>> copying.
>
>I don't see how "shallow copying" is possible if the compiler is
>responsible.

No, you're right.  The default would be for `move' to do a deep
copy.  But `move' would be a template function that could be
specialized by users (for user-defined classes) or library
implementors (e.g. for the STL classes) to do a more efficient
shallow copy.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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
]

Fergus Henderson (fjh@murlibobo.cs.mu.OZ.AU) wrote:
: tony@online.tmx.com.au (Tony Cook) writes:
: >But you're assuming that the underlying model can split a realloc()
: >into it's two special cases: expand in place and free/malloc.

: That might be necessary to implement renew[] with maximal efficiency,
: but you easily could implement renew[] without delving into the internals
: of realloc(), just by calling malloc() and free() rather than realloc().

This maximal efficiency seems to be the main reason for wanting
renew[].

: But to make it really useful, you'd need a standard `move' function,
: combining construction of the target and destruction of the source,
: which could be specialized to do shallow copying rather than deep
: copying.  It's a pity that STL didn't include such a function.

It could certainly be used to make vector<T> more efficient.


--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.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
]

In article <5c8km3$ngs@panix.com> comeau@panix.com (Greg Comeau) writes:
>(2) A "C++ object" != raw memory.
>    This is a problem -- at least an issue -- because of things such as
>    constructors, copying objects (which realloc() is allowed to do!)
>    and this seems to leave open a number of questions about copy semantics
>    and when and what makes sense.

Is there any question about which constructors should be called?
Apart from whether the copy constructors should be applied starting
from the beginning or end of the array?

>(3) You can use/create a container class with known semantics.

But that begs the question of "new[]" and "delete[]" haven't been
designated obsolescent.  Given that they are still part of the
language, there should be a "renew[]" as well.  It would need
the array length as used by delete[].  I.e. it cannot be done in C++
but it can be done, and easily, in the underlying model that is
required to implement C++.  That seems to me a good argument for
implementing it.
---
[ 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                             ]

A. Grant (ag129@ucs.cam.ac.uk) wrote:
: But that begs the question of "new[]" and "delete[]" haven't been
: designated obsolescent.  Given that they are still part of the
: language, there should be a "renew[]" as well.  It would need
: the array length as used by delete[].  I.e. it cannot be done in C++
: but it can be done, and easily, in the underlying model that is
: required to implement C++.  That seems to me a good argument for
: implementing it.

But you're assuming that the underlying model can split a realloc()
into it's two special cases: expand in place and free/malloc.

And the first case can be split into three further cases which have
an effect on implementing renew: expand upwards, expand downwards,
expand both ways.

Only one operating system (or environment) out of the three I know
well can split these operations: MS-DOS vs Win16 and Win32.

The split is necessary, since the normally realloc() functions
supported by the Win16/32 API will only perform a bitwise copy.

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com
---
[ 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                             ]

tony@online.tmx.com.au (Tony Cook) writes:

>A. Grant (ag129@ucs.cam.ac.uk) wrote:
>: But that begs the question of "new[]" and "delete[]" haven't been
>: designated obsolescent.  Given that they are still part of the
>: language, there should be a "renew[]" as well.  It would need
>: the array length as used by delete[].  I.e. it cannot be done in C++
>: but it can be done, and easily, in the underlying model that is
>: required to implement C++.  That seems to me a good argument for
>: implementing it.
>
>But you're assuming that the underlying model can split a realloc()
>into it's two special cases: expand in place and free/malloc.

That might be necessary to implement renew[] with maximal efficiency,
but you easily could implement renew[] without delving into the internals
of realloc(), just by calling malloc() and free() rather than realloc().

But to make it really useful, you'd need a standard `move' function,
combining construction of the target and destruction of the source,
which could be specialized to do shallow copying rather than deep
copying.  It's a pity that STL didn't include such a function.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

Fergus Henderson wrote:

> But to make it really useful, you'd need a standard `move' function,
> combining construction of the target and destruction of the source,
> which could be specialized to do shallow copying rather than deep
> copying.

I don't see how "shallow copying" is possible if the compiler is
responsible.  Obviously it cannot be a bitwise copy, because that breaks
objects that (among other things) contain pointers to their own
members.  The other alternative is the copy ctor, which is hardly
shallow.  Perhaps you mean that each object could implement a move()
method, which I think must be like a shallow-copy ctor.  But this places
rather odd requirements on classes that are to be used as the target of
renew[].

IMHO it would be good to have a renew[] that at least optimized for the
case where memory can be expanded (or shrunk) in-place at the end of the
array, thus eliminating the need for copying in some special cases.
Next standard, maybe?

john lilley
---
[ 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 <5dj9u2$d64@news.tmx.com.au> tony@online.tmx.com.au (Tony Cook) writes:
>But you're assuming that the underlying model can split a realloc()
>into it's two special cases: expand in place and free/malloc.
>And the first case can be split into three further cases which have
>an effect on implementing renew: expand upwards, expand downwards,
>expand both ways.

Who says renew[] has to use realloc()?  Maybe it could use realloc()
only for types with bitwise copy semantics, and do other arrays
with malloc/free.


[ 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 <5djru7$cqt@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU
(Fergus Henderson) wrote:

>>
>>But you're assuming that the underlying model can split a realloc()
>>into it's two special cases: expand in place and free/malloc.
>
>That might be necessary to implement renew[] with maximal efficiency,
>but you easily could implement renew[] without delving into the internals
>of realloc(), just by calling malloc() and free() rather than realloc().
>
>But to make it really useful, you'd need a standard `move' function,
>combining construction of the target and destruction of the source,
>which could be specialized to do shallow copying rather than deep
>copying.  It's a pity that STL didn't include such a function.
>

This is not trivial -- some objects will have pointers/references to other
objects that (directly or indirectly) have pointers back to the original.

You would have to allow each class to provide its own move function.
--
Darron Shaffer
Darron.Shaffer@beasys.com




[ 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 n5yEpfhS6L092yn@nada.kth.se, d96-mst@nada.kth.se (Mikael St   ldal) writes:
>Why aren't there any realloc() like thing for new/delete?

This question has been raised and discussed to death many times in this
newsgroup.

A "re-new" operation would have to do something like this, assuming you
are asking for more space:
 1. allocate enough space for the new array
 2. copy-construct each old object into the new array in order.
 3. destroy each old object in reverse order.
 4. delete the old array
 5. fill the remainder of the new array by constructing new objects
  with the no-argument constructor (if there isn't one,
  the re-new is illegal).

The main original reason for not providing a "re-new" was that you would
normally prefer to write a more efficient special-case version yourself.
In addition, copying the object and destroying the original might not
be the proper thing to do (it might hold a resource that would prevent
copying it), but a general-purpose "re-new" has no choice but to use
the above algorithm.

Another reason was that you should not be creating C-style resizeable
arrays of class objects anyway. Create (if you must) arrays of pointers to
unmoving objects, and you can use malloc/realloc/free for those.

A newer reason is that the standard library now provides a number of
alternatives to C-style arrays, and you should use those instead,
particulary since they directly support resizing.
---
Steve Clamage, stephen.clamage@eng.sun.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
]

d96-mst@nada.kth.se (Mikael Steldal) writes:
>>Why aren't there any realloc() like thing for new/delete?

stephen.clamage@Eng.Sun.COM (Steve Clamage) writes:
>This question has been raised and discussed to death many times in this
>newsgroup.

>A "re-new" operation would have to do something like this, assuming you
>are asking for more space:
> 1. allocate enough space for the new array
> 2. copy-construct each old object into the new array in order.
> 3. destroy each old object in reverse order.
> 4. delete the old array
> 5. fill the remainder of the new array by constructing new objects
>  with the no-argument constructor (if there isn't one,
>  the re-new is illegal).

This is exactly what the STL vector class does when a vector is grown,
pretty much exactly as Steve wrote it (at least in the HP and SGI
implementations).  To the extent that this is satisfactory, Steve could
have written that it is already supported.  That is, if the above is what
re-new should be, it's already in there, built into vector<T>.  And
vector<T> can be dropped into most code that is written in terms of arrays.

However, there are certain problems with this; it is needlessly
inefficient in many cases.  For most more complex classes, there is
a much more efficient way of implementing the frequently occurring
operation of object movement.  Object movement is almost always implemented
correctly by following a copy-construction operation into raw space
(allocated from an allocator) followed by destruction of the original.
However, for many classes a shallow copy operation would achieve the
same result with far less work.

All that's needed to gain this greater efficiency is to define a new
standard library template, called relocate, whose default behavior
is uninitialized_copy followed by destroy, but that can be specialized
for a class.  The usual specialization for an object with pointers to
data on the heap would just be a shallow copy.  Next, STL algorithms
and other code that does data relocation would be written in terms of
this template.  A similar specializable template could be made available
for the swap operation.

Any implementer can provide a __relocate template and use the above
techniques to improve the performance of vectors of strings considerably.
But ideally, the standards committee would provide a standard way
of doing fast relocation, since it fits in so easily with the STL model.
Is it too late to do this now?

>The main original reason for not providing a "re-new" was that you would
>normally prefer to write a more efficient special-case version yourself.

Exactly.  Wouldn't it be nice if all the STL algorithms could use this
special-case version, though?

>In addition, copying the object and destroying the original might not
>be the proper thing to do (it might hold a resource that would prevent
>copying it), but a general-purpose "re-new" has no choice but to use
>the above algorithm.

Not true, as I show above: template specialization allows the "right
thing" to happen.  For example, it could help make vector<auto_ptr<T> >
work correctly, by generating the correct code to relocate an auto_ptr.



--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://www.vix.com/spam/
---
[ 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 <5+n5yEpfhS6L092yn@nada.kth.se> d96-mst@nada.kth.se
(Mikael Steldal) writes:
>Why aren't there any realloc() like thing for new/delete?

Some reasons there is no renew include:
(1) realloc() in C is not all that it is cracked up to be.
    For instance, it can lead to further memory fragmentation.
    Or, it may or may not copy the memory.
    And, what about if it fails?  renew would be no different.
(2) A "C++ object" != raw memory.
    This is a problem -- at least an issue -- because of things such as
    constructors, copying objects (which realloc() is allowed to do!)
    and this seems to leave open a number of questions about copy semantics
    and when and what makes sense.
(3) You can use/create a container class with known semantics.
(4) If you do something such as "placement new", class new, etc,
    you can also create your own renew() or grow() member function
    since you'll be in sync on what it is supposed to do or not.
(5) ctors are considered when something is new'd.
    Consider what those semantics would (or would not) mean in a
    _standard_ renew.
(6) renew does not imply realloc() capability, so, it seems, it is not
    the right name.

For a split second, it seem renew should be available.
But as in many things, intuition or first thoughts are often
not correct.  Remember that the elements (not just their memory)
must be copied.  Also, side-effects (for instance, ctors/dtors) must be
considered.  Resizing "in place" is not particularly an option.
The bottom line here is that your class knows itself,
and hence should be in control of its own memory management.
It's absence "is the right thing" as I cannot see an acceptable
average situation for this.... at least not with user-defined types.
Personally then I feel it necessary renew was and continues to be omitted.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 /Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com /CIS:72331,3421
---
[ 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                             ]

Why aren't there any realloc() like thing for new/delete?


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