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

Martin Sebor msebor@gmail.com
Tue May 11 20:02:59 GMT 2021


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
> 



More information about the Gcc-patches mailing list