From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id D5A64393BC3D for ; Mon, 3 May 2021 21:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D5A64393BC3D Received: by mail-qk1-x733.google.com with SMTP id q136so6693421qka.7 for ; Mon, 03 May 2021 14:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hOhg4nGBbOm4/3L8afvrFrnOsTeyh/rEgzgREWBVEP0=; b=gB1ubTK8GoUCRBEi5KFgZ0xQ/bcODqGdXJr/IZAgKHCX0nUAWFSlamwcBPJ4ci/Ber Le6+rpIDOAbi2oYsfNIt6qN3BfiZW/Ls4AW5Oyvj4ZxdT7QEV0o7c1Vj1j0UAGgFmufK UTE15HgU9tPl/0RYXVeEE+yYrlMgc2UJj1UKzPRTJ3qUvcm0mSF44H4LDyJlGTfL+UAE duaowXH89ArbyOhfLVLW3z7aFQ7x6c6O3daL2OkEIUzIrUFVjuF7tPUsj/fQmAN2yjS4 vRAAEXk9R7tRvw9G0+0mLyEji3fTFKNyviJurzrzfzjpfclIlQtJDKpKixDUbYWwfjjY BnbA== X-Gm-Message-State: AOAM530oTVue5mDH54AICeFGoGiER8xg/mlUiS7Qpm+RO4L896CC8xFe alyRVxj6u0QXf3+KidkD9N5NbS1Zt2g= X-Google-Smtp-Source: ABdhPJxbNDuEf8wXW8eMydN7Z0/odFzIBLo2nynZ14fBIYCufH3kZK697ViRiTVyL0Hl7cWYVTZG1w== X-Received: by 2002:a37:ac7:: with SMTP id 190mr14794079qkk.452.1620078635355; Mon, 03 May 2021 14:50:35 -0700 (PDT) Received: from [192.168.0.41] (71-218-14-121.hlrn.qwest.net. [71.218.14.121]) by smtp.gmail.com with ESMTPSA id o78sm6456297qke.98.2021.05.03.14.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 14:50:34 -0700 (PDT) Subject: [PING][PATCH] define auto_vec copy ctor and assignment (PR 90904) From: Martin Sebor To: Richard Biener Cc: gcc-patches References: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> Message-ID: Date: Mon, 3 May 2021 15:50:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 21:50:38 -0000 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 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 >>>> 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