[PING 3][PATCH] define auto_vec copy ctor and assignment (PR 90904)

[Martin Sebor <msebor@gmail.com>]

Jason, I wonder if you could review this patch that Richard has
apparently decided to defer to others.

https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html

Thanks

On 5/11/21 2:02 PM, Martin Sebor wrote:
> Ping 2:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
> 
> 
> On 5/3/21 3:50 PM, Martin Sebor wrote:
>> Ping:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
>>
>> On 4/27/21 9:52 AM, Martin Sebor wrote:
>>> On 4/27/21 8:04 AM, Richard Biener wrote:
>>>> 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)
>>>
>>> The vec base classes are special: they have no ctors at all (because
>>> of their use in unions).  That's something we might have to live with
>>> but it's not a model to follow in ordinary containers.
>>>
>>> The auto_vec class was introduced to fill the need for a conventional
>>> sequence container with a ctor and dtor.  The missing copy ctor and
>>> assignment operators were an oversight, not a deliberate feature.
>>> This change fixes that oversight.
>>>
>>> The revised patch also adds a copy ctor/assignment to the auto_vec
>>> primary template (that's also missing it).  In addition, it adds
>>> a new class called auto_vec_ncopy that disables copying and
>>> assignment as you prefer.  It also disables copying for
>>> the auto_string_vec class.
>>>
>>> Martin
>>
>