Re: [boost] auto_vector - vector with auto_ptr semantics

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-05 12:22:32

From: "Rainer Deyke" <root_at_[hidden]>
> ----- Original Message -----
> From: "Howard Hinnant" <hinnant_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, February 05, 2002 9:57 AM
> Subject: Re: [boost] auto_vector - vector with auto_ptr semantics
>
>
> > On Tuesday, February 5, 2002, at 11:38  AM, Peter Dimov wrote:
> >
> > > And let's not forget the 'other' move, that moves an object into
> > > uninitialized memory (move1 and swap both require two objects to
> operate
> > > on.) std::vector needs this while reallocating.
> >
> > Yup!  A minimum of 2 types of move are absolutely necessary:
> >
> > 1.  Move construct.
> > 2.  Move assign.
> >
> > One could argue that 2 more moves are useful:
> >
> > 3.  Move construct, destructing the source.
> > 4.  Move assign, destructing the source.
> >
> > However 3 and 4 are very easily built on 1 and 2 by just calling the
> > destructor on the source after the move.
>
> Not necessarily: sometimes an object must hold resources to maintain
> class invariants.   For example:
>
>   class C {
>   public:
>     C() : fp(fopen("myfile", "rb")
>     {
>       if (!this->fp) throw something;
>     }
>     ~C()
>     {
>       fclose(fp); /* Do not check for null. */
>     }
>   private:
>     FILE *fp;
>   };

That's why I prefer 2. and 3., not 1. and 2. (keeping the object count
constant, so to speak.) We either start with two objects A and B and move B
into A, or we start with object A and raw memory R and end up with object R'
and raw memory A'.

This makes sense, hopefully. :-)