From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 69ABD385780B for ; Thu, 27 May 2021 20:53:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69ABD385780B Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234-AnmKoZgWMmmG4SpVvA4gyg-1; Thu, 27 May 2021 16:53:39 -0400 X-MC-Unique: AnmKoZgWMmmG4SpVvA4gyg-1 Received: by mail-qt1-f198.google.com with SMTP id x19-20020ac87a930000b02901f6125bcda0so895364qtr.19 for ; Thu, 27 May 2021 13:53:38 -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:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bsxMU37dHth5rCiZ7HqxsRMSrU6DZTeE9kXd7LOIaYY=; b=QmTPW4x/KJkiqzpYoTl/vt/eN+ry5TmtBHo2wOESKvmJrTEDqpZfDMEwnVk+m9A+el KE7M36Pm4w3aNWTAFYng+pMOCuizgVU5rWzclRXSUMZN3oFipJudqG3/u5e3UvXaVEBT eWS5EC3UPjwJJZ992qK25j3kWgrNaDY1KK2vbmN23HokiNSoXrYJm2ZsgRJE9kvFIyBa ffSwl/WkaNYhTPT4P44W22XfOf5y08of5Oe5psCGx/mgvmMdZ84TaTRL5LQUSQPB/ECj qilsof5c0hoHAUJnXxUDM+luTfD47yXko2/ytTO2YYi7tCstwDAxyOvLewkNGgYpik7Z QWyw== X-Gm-Message-State: AOAM532jEE5LKYlUmef+DTt/iay5BmDvec6NE14QafQYCAAaC0f8MGN2 MaciR7ZsDnhMyJzPWPQBh78ugUUOjafpRNj78jYmyUzSgGAD9fQJfa+VooWZbepi5t7AlSE1Eim BzNxsgk7j9dW3UR/niA== X-Received: by 2002:a37:7d0:: with SMTP id 199mr465995qkh.108.1622148818535; Thu, 27 May 2021 13:53:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjoa0Fv3txRaTKzHx+zJVWI5cB+Wh2QfrZ2yYhPo7wOW1trWqtXgwOlmOdUrP5BpQOxiqFtA== X-Received: by 2002:a37:7d0:: with SMTP id 199mr465965qkh.108.1622148818091; Thu, 27 May 2021 13:53:38 -0700 (PDT) Received: from [192.168.1.148] ([130.44.159.43]) by smtp.gmail.com with ESMTPSA id b123sm2169141qke.87.2021.05.27.13.53.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 May 2021 13:53:37 -0700 (PDT) Subject: Re: [PATCH] define auto_vec copy ctor and assignment (PR 90904) To: Martin Sebor , Richard Biener Cc: gcc-patches , Jonathan Wakely References: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> From: Jason Merrill Message-ID: <4d503394-4e82-1d36-41ca-34315042775b@redhat.com> Date: Thu, 27 May 2021 16:53:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <91545a73-12af-33b2-c6e7-119b5a21de60@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Thu, 27 May 2021 20:53:42 -0000 On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches 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. I don't think we have to live with it anymore, now that we're writing C++11. > 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. Hmm, adding another class doesn't really help with the confusion richi mentions. And many uses of auto_vec will pass them as vec, which will still do a shallow copy. I think it's probably better to disable the copy special members for auto_vec until we fix vec<>. Jason