From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29210 invoked by alias); 22 Sep 2016 19:35:36 -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 29199 invoked by uid 89); 22 Sep 2016 19:35:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.5 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,MSGID_MULTIPLE_AT,RCVD_IN_SEMBACKSCATTER autolearn=no version=3.3.2 spammy=gdbpatchesownersourcewareorg, gdb-patches-owner@sourceware.org, U*gdb-patches-owner, septembre X-HELO: mailhost.u-strasbg.fr Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.222.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Sep 2016 19:35:29 +0000 Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antispam (Postfix) with ESMTP id 377492232E7; Thu, 22 Sep 2016 21:35:26 +0200 (CEST) Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id 24CA2222B75; Thu, 22 Sep 2016 21:35:26 +0200 (CEST) Received: from local-mr.u-strasbg.fr (lmr2.u-strasbg.fr [172.30.21.2]) by mr1.u-strasbg.fr (Postfix) with ESMTP id E8840223490; Thu, 22 Sep 2016 21:35:22 +0200 (CEST) Received: from local-mr.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id B4638AF; Thu, 22 Sep 2016 21:35:22 +0200 (CEST) Received: from E6510Muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (Authenticated sender: mullerp) by lmr2.u-strasbg.fr (Postfix) with ESMTPSA id 53CEEA1; Thu, 22 Sep 2016 21:35:18 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" , "'Tom Tromey'" Cc: References: <1474566656-15389-1-git-send-email-tom@tromey.com> <1474566656-15389-4-git-send-email-tom@tromey.com> <89b014ab-704c-bb8e-2e1a-6361efa5a644@redhat.com> <87bmzf21bf.fsf@tromey.com> <1b62c1c7-31ec-38c7-e4b4-25fdc560388c@redhat.com> In-Reply-To: <1b62c1c7-31ec-38c7-e4b4-25fdc560388c@redhat.com> Subject: RE: [RFA 3/5] Use std::string, std::vector in rust-lang.c Date: Thu, 22 Sep 2016 20:37:00 -0000 Message-ID: <000f01d21508$755322b0$5ff96810$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-09/txt/msg00298.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: jeudi 22 septembre 2016 21:25 > =C0=A0: Tom Tromey > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFA 3/5] Use std::string, std::vector in rust-lang.c >=20 > On 09/22/2016 08:15 PM, Tom Tromey wrote: > >>>>>> "Pedro" =3D=3D Pedro Alves 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. >=20 > In C, it'd require C99, while we were C89. Other than that, > it was just a coding convention. >=20 > 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?=20 =20 > 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...