Re: [PATCH] define auto_vec copy ctor and assignment (PR 90904)

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor <msebor@gmail.com> wrote:
>
> On 4/27/21 1:58 AM, Richard Biener wrote:
> > On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> PR 90904 notes that auto_vec is unsafe to copy and assign because
> >> the class manages its own memory but doesn't define (or delete)
> >> either special function.  Since I first ran into the problem,
> >> auto_vec has grown a move ctor and move assignment from
> >> a dynamically-allocated vec but still no copy ctor or copy
> >> assignment operator.
> >>
> >> The attached patch adds the two special functions to auto_vec along
> >> with a few simple tests.  It makes auto_vec safe to use in containers
> >> that expect copyable and assignable element types and passes bootstrap
> >> and regression testing on x86_64-linux.
> >
> > The question is whether we want such uses to appear since those
> > can be quite inefficient?  Thus the option is to delete those operators?
>
> I would strongly prefer the generic vector class to have the properties
> expected of any other generic container: copyable and assignable.  If
> we also want another vector type with this restriction I suggest to add
> another "noncopyable" type and make that property explicit in its name.
> I can submit one in a followup patch if you think we need one.

I'm not sure (and not strictly against the copy and assign).  Looking around
I see that vec<> does not do deep copying.  Making auto_vec<> do it
might be surprising (I added the move capability to match how vec<>
is used - as "reference" to a vector)

Richard.

> Martin