From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81938 invoked by alias); 6 Oct 2016 00:39:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 81929 invoked by uid 89); 6 Oct 2016 00:39:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=initializers, Hx-languages-length:1133, Worth X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Oct 2016 00:39:07 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F421D90E5F; Thu, 6 Oct 2016 00:39:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u960d4ip007767; Wed, 5 Oct 2016 20:39:04 -0400 Subject: Re: [RFA 01/22] Change selttest.c to use use std::vector To: Tom Tromey , Trevor Saunders References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-2-git-send-email-tom@tromey.com> <20160927084049.naw5nx64smlzpqxg@ball> <87twd1z6a7.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 06 Oct 2016 00:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87twd1z6a7.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00095.txt.bz2 On 09/27/2016 04:55 PM, Tom Tromey wrote: > Trevor> should we use a pointer to avoid the static initializer? > > I was on the fence about this one. > On the one hand, static initializers can be very bad. > On the other hand, this one in particular doesn't seem like it could > cause problems. I think it's OK for now. The patch LGTM. We may want to revisit later. I guess with "can be very bad" you're thinking of order of constructors between compilation units. Worth keeping in mind is the not making the library use case harder to get at in the future, considering the potential need for controlled bring up (static ctors) and teardown (static dtors) independent of exit() time. Yet another aspect worth considering is the startup time overhead impact of global constructors. VEC has a POD base class which allows avoiding that: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01651.html See LLVM here considering/doing similar things: https://llvm.org/bugs/show_bug.cgi?id=11944 But that feels like premature optimization too me at this point. Thanks, Pedro Alves