From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 16EC53858D35 for ; Fri, 7 Aug 2020 09:17:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16EC53858D35 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-f0tEFdyvP2amDugnxMSGpQ-1; Fri, 07 Aug 2020 05:17:32 -0400 X-MC-Unique: f0tEFdyvP2amDugnxMSGpQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 270CB10059A8; Fri, 7 Aug 2020 09:17:31 +0000 (UTC) Received: from localhost (unknown [10.33.36.145]) by smtp.corp.redhat.com (Postfix) with ESMTP id 98B0910023A7; Fri, 7 Aug 2020 09:17:30 +0000 (UTC) Date: Fri, 7 Aug 2020 10:17:29 +0100 From: Jonathan Wakely To: Jakub Jelinek Cc: Richard Biener , Andrew MacLeod via Gcc-patches Subject: Re: std:vec for classes with constructor? Message-ID: <20200807091729.GO3400@redhat.com> References: <20200806104835.GX3400@redhat.com> <20200806163045.GE3400@redhat.com> <20200806192410.GI3400@redhat.com> <20200807075746.GK3400@redhat.com> <20200807083438.GL3400@redhat.com> <20200807085508.GA2363@tucnak> MIME-Version: 1.0 In-Reply-To: <20200807085508.GA2363@tucnak> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: Fri, 07 Aug 2020 09:17:35 -0000 On 07/08/20 10:55 +0200, Jakub Jelinek wrote: >On Fri, Aug 07, 2020 at 09:34:38AM +0100, Jonathan Wakely via Gcc-patches wrote: >> > Now that you say it, vec has a T[1] member so depending on T >> > there might be a side-effect as invoking its CTOR? Or it might >> > even not compile if there is no default CTOR available... Ick :/ >> >> Right. >> >> Does the GTY stuff add members to the struct, or otherwise alter its >> layout? > >Or perhaps use offsetof on an alternate structure that should have the same >layout. Yes that's what I was going to suggest next. >So instead of > typedef vec vec_embedded; > return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); >use > struct alignas (T) U { char data[sizeof (T)]; }; > typedef vec vec_embedded; static_assert(sizeof(vec_embedded) == sizeof(vec), ""); static_assert(alignof(vec_embedded) == alignof(vec), ""); > return offsetof (vec_embedded, m_vecdata) + alloc * sizeof (T); >where vec_embedded should have the same offset of m_vecdata as vec.