On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor <mse...@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
