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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id BB108385E44A for ; Wed, 14 Jul 2021 10:47:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB108385E44A Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-vw19eZW4OnuY0YxAaA_kgw-1; Wed, 14 Jul 2021 06:47:37 -0400 X-MC-Unique: vw19eZW4OnuY0YxAaA_kgw-1 Received: by mail-wr1-f72.google.com with SMTP id r18-20020adfce920000b029013bbfb19640so1280218wrn.17 for ; Wed, 14 Jul 2021 03:47:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9CnHgaeBT9evAgtn2GmGYu5M39CaD1iTzL+le3tBXwI=; b=Ta5r4NTTr+RgUSbkIYoZcQmQMWJPN+DSa+b2QXf6Dpu6ZF0ui9bYyTXuEDXCMfxx5T fPTv7/+AeJ7xy36x1R1JxHEFoymukb7wx54OctJ2TfSgK2jzijZU159ER7Rb0PSwHioU x9/iurdyKVc4zmZiTRIl5OEBjfKBIQo4MXQZrnfo6eYsnEj/AqXX8M3+9WF/MS9gff7T AaCvZyr9TJXKz//v4dAyJYRMsPk3GfQxPefCP9GVfK+ONZDKpxxh9LzjtBq4af5XC1F7 omzdt7AdkJtJsR2vMnwns6y2lXr2slqXnhKrw1UVs9HG+7rWZf1zSWozSoo4H2AqyNHP 9+Ew== X-Gm-Message-State: AOAM530NBmqelzpmY9YuO5LfX4B7cG258R+gUUjvJQU5D9eLYG+Zy2tx tczzEIsrXsci83qdgsQfL0Cd44wp9HxF6M4bwcvhB2pFld+VMluotN7LpNlspA5m5OBPjrDnNUA tnxMnJML6F97mUkDCUIcqOUOUd/yg6sX1iQ== X-Received: by 2002:adf:e7c6:: with SMTP id e6mr12080091wrn.221.1626259656064; Wed, 14 Jul 2021 03:47:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxSKwkJ40sAys8LiEeN+eV5eZkAPDC2dUCDA+eJyOZ16jTX9OGBoY/XGh92c75L90KMj8Z7Vm9ACvOpSZTJEp4= X-Received: by 2002:adf:e7c6:: with SMTP id e6mr12080069wrn.221.1626259655864; Wed, 14 Jul 2021 03:47:35 -0700 (PDT) MIME-Version: 1.0 References: <4d503394-4e82-1d36-41ca-34315042775b@redhat.com> <49569f1d-9856-55c7-b9e9-578bbd7c7b7a@gmail.com> <390c6652-0a1f-e8c4-d70d-56ced2f7b0fb@gmail.com> <0ee2488c-04a1-df3b-dd4f-92eec51a4ab2@redhat.com> <7ebb37f3-76c3-8e00-7852-c93bf142043a@gmail.com> <2c60a7d0-3f60-b72f-c0f2-6fc7a4900740@redhat.com> In-Reply-To: <2c60a7d0-3f60-b72f-c0f2-6fc7a4900740@redhat.com> From: Jonathan Wakely Date: Wed, 14 Jul 2021 11:47:24 +0100 Message-ID: Subject: Re: [PING][PATCH] define auto_vec copy ctor and assignment (PR 90904) To: Jason Merrill Cc: Martin Sebor , Richard Biener , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 14 Jul 2021 10:47:40 -0000 On Wed, 14 Jul 2021 at 04:39, Jason Merrill wrote: > > On 7/13/21 4:02 PM, Martin Sebor wrote: > > On 7/13/21 12:37 PM, Jason Merrill wrote: > >> On 7/13/21 10:08 AM, Jonathan Wakely wrote: > >>> On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote: > >>>> Somebody with more C++ knowledge than me needs to approve the > >>>> vec.h changes - I don't feel competent to assess all effects of the > >>>> change. > >>> > >>> They look OK to me except for: > >>> > >>> -extern vnull vNULL; > >>> +static constexpr vnull vNULL{ }; > >>> > >>> Making vNULL have static linkage can make it an ODR violation to use > >>> vNULL in templates and inline functions, because different > >>> instantiations will refer to a different "vNULL" in each translation > >>> unit. > >> > >> The ODR says this is OK because it's a literal constant with the same > >> value (6.2/12.2.1). > >> > >> But it would be better without the explicit 'static'; then in C++17 > >> it's implicitly inline instead of static. > > > > I'll remove the static. > > > >> > >> But then, do we really want to keep vNULL at all? It's a weird > >> blurring of the object/pointer boundary that is also dependent on vec > >> being a thin wrapper around a pointer. In almost all cases it can be > >> replaced with {}; one exception is == comparison, where it seems to be > >> testing that the embedded pointer is null, which is a weird thing to > >> want to test. > > > > The one use case I know of for vNULL where I can't think of > > an equally good substitute is in passing a vec as an argument by > > value. The only way to do that that I can think of is to name > > the full vec type (i.e., the specialization) which is more typing > > and less generic than vNULL. I don't use vNULL myself so I wouldn't > > miss this trick if it were to be removed but others might feel > > differently. > > In C++11, it can be replaced by {} in that context as well. Or if people don't like that, you could add a constructor taking std::nullptr_t and an equality comparison with std::nullptr_t and then use nullptr instead of vNULL. I think just using {} for an empty, value-initialized vec makes more sense though.