From: thoth@wave.cis.ufl.edu (Robert Forsman)
Newsgroups: comp.lang.c++
Subject: Re: Renew?
Date: 25 Jul 92 15:00:48 GMT
	<1992Jul4.173316.11890@taumet.com> <1992Jul5.002414.390@frumious.uucp>
Organization: Church of Homogeneous Foods (Rev. Forsman founder)
In-reply-to: pat@frumious.uucp's message of 5 Jul 92 00:24:14 GMT


#define DOGMATIC

In article <1992Jul5.002414.390@frumious.uucp> pat@frumious.uucp (Patrick Smith) writes:

 > I believe that renew would be a useful addition to the language,
 > but only if it allowed the possibility of not moving the array.

The absence of an analog for realloc is one of my MAJOR gripes with
C++

 > I'm not sure whether it would be useful _enough_ to warrant
 > adding it, or to warrant spending X3J16's time on it (they have
 > enough things to do already!).

#ifdef DOGMATIC
#if !BELIEVE_COMMITTEE_WILL_MUCK_IT_UP
  It is.  If they're too busy considering other stuff, they can put it
on hold.  This is more important.
#else
  I'd rather see a sample implementation first.  I trust gravity by 5
orders of magnitude more than I trust any committee.  It's very likely
that they'll muck it up if they haven't got something solid to look at
(and even then, horse shit gets solid when you refrigerate it).
#endif
#endif

 >  If it were to be added, these are
 > the semantics I would suggest (with a warning: I have _not_
 > thought this through thoroughly):

 > 4) If neither (2) nor (3) holds, then the following steps are
 >    performed:
 >
 >    a) Allocate the new space.
 >    b) For each element in the old array (in order from first to last),
 >       copy the element to its position in the new array by calling
 >       the copy constructor and then the destructor.
 >    c) Call the default constructor for the extra elements of the
 >       new array.
 >    d) Deallocate the unused space from the old array.
 >

  Well, I'm not sure I like that.  I'd much rather see a bcopy instead
of a copy construction and a deletion in almost every case (almost).
I may have missed the discussion about why this is bad.

  Why not have ANOTHER special method (in addition to copy
construction, deletion and assignment) which is only called when an
object is being MOVED from one memory location to another?  (please
note that I am not overjoyed at the idea of another special operator.
I merely expect that the default will work fine for everything I do.)

  I don't see why you have to perform a copy construction (which is
often expensive) + a deletion (which is often cheap) instead of a
bcopy (ultra-cheap).  The only case I can think of where bcopy would
cause violation of invariants is if the object contained pointers to
its data members or if someone else had pointers to its data members.
Then you would write the relocator routine for that class.  The
default relocator routine would simply be a bcopy.

  I wonder if the relocator would come in handy in other situations.
/* begin half-serious meander */ If you consider the relocator as an
optimization of the cp-construction/destruction sequence, how about
another optimizer for the assignment/destruction sequence?  I can see
it now, blah::operator=~( const blah &).  I'm sure there's another
combination that I can't think of right now, but it will come to me.
I can imagine such things would be useful when passing parameters,
returning values and assigning from temporaries.  /* end meander */
Seriously, that idea is Copyright (C) 1992 me.  Any bad trips you have
because you took it seriously are your own fault and I'm not going to
take the blame (though I will accept cash donations).


  I think I have a reasonable stake in the outcome of this discussion
because I'm part of the team implementing Image Algebra C++.  If we
don't get a renew operator, we'll be forced to choose between wasting
time and possibly wasting space.  (consider an image extension or a
Yoder PointSet operation).  Granted, we're not writing missile
targeting routines (but our end-users might be >:).

  If what I've said has already been discussed (I don't read this
group usually), take it as either evidence of ESP (you wacky louts),
or as evidence that GLARINGLY OBVIOUS (while sometimes abominable)
solutions are GUARANTEED to be invented independently.
--
Eat now this hot-dog with ketchup, flesh of his flesh, blood of his blood.
I deal with Reality as you _don't_ understand it. 
blah = realloc(blah, sizeof(*blah)*(blahsize*=2)); /* (TM) */