This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFA 3/5] Use std::string, std::vector in rust-lang.c
> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : jeudi 22 septembre 2016 21:25
> À : Tom Tromey
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA 3/5] Use std::string, std::vector in rust-lang.c
>
> On 09/22/2016 08:15 PM, Tom Tromey wrote:
> >>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> >
> > Pedro> So I think we should move the variable declaration to the
> > Pedro> initialization line, to avoid default constructing the
> variable
> > Pedro> and then resetting it afterwards, as the compiler may
> > Pedro> not be smart enough to elide that.
> >
> > I think so too -- I had avoided this on account of earlier objections
> to
> > this style.
>
> In C, it'd require C99, while we were C89. Other than that,
> it was just a coding convention.
>
> But we now have technical reasons for not putting variables
> at top of the scope. There's the efficiency reason, and then
> some types may not even have a default constructor, and the
> arguments that'd need to be passed to the constructor
> might not have been computed at the top of the scope, making
> it impossible to declare the variable at the top, unless we'd
> open an ugly new scope...
Just out of curiosity:
how are such variables treated by gcc regarding debug information?
What is the scope of definition of those variables?
And is it correctly handled by current GDB?
IIRC (but my knowledge about C++ if far
worse than for plain C.. which itself I only learned to be able to
contribute to GDB...) the reason why we can remove the cleanups is
that the compiler will insert auto--magically
the destructors of those local variables at the end of
their respective scope, is this correct?
> So I think there's no ground for objection.
Not that I want to raise an objection,
I just wonder if debugging GDB by itself will remain as easy as it was!
Pierre Muller
pascal language support maintainer...