This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 01/22] Change selttest.c to use use std::vector
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>, Trevor Saunders <tbsaunde at tbsaunde dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 6 Oct 2016 01:39:03 +0100
- Subject: Re: [RFA 01/22] Change selttest.c to use use std::vector
- Authentication-results: sourceware.org; auth=none
- 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>
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