From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39844 invoked by alias); 26 May 2017 14:10:04 -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 39829 invoked by uid 89); 26 May 2017 14:10:03 -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_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=admit X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 May 2017 14:10:01 +0000 Received: by mail-wm0-f51.google.com with SMTP id d127so22034583wmf.0 for ; Fri, 26 May 2017 07:10:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hgN8EaMDxQJFxpf9j88vrp4sXXEaIZad9cTUWm83ifw=; b=nxodd6alpn+t4PtognZh9wFm1X2yYlgxHwXq4qFr6jejq6dovQQc51GeFKOmOCDzv8 QBUGysy3xyFphHSY4vOHuiTfweW51RFJwX9DqWsSv0fbZMExjXtXmTdfP2d9ao47lGUS fZm0DLPVu8TGXcymZOay5t5drwDmD95pmkkGxs92wPS94fQy0r13RvejHC2XjKMm3e9B nzu71wqFfs4GweoOji1kRbmlZHM+UhGK1uvZ9yV/I6v8ceMlM5ua+Hc5JpfellFpqnaO YuUCUYb7XlAM2870EejSfZrkzrBmtJY5FJcBDyAtFgD1wm/ObefuusBnarzXy39ML1mA orqQ== X-Gm-Message-State: AODbwcDGTf6qu/tfW4MriaUdseohX3+SMusn37BkQdRurTaDLHMMkNpP nqlCoNmvCyFwcom8q3u9wg== X-Received: by 10.28.109.29 with SMTP id i29mr2134344wmc.113.1495807803007; Fri, 26 May 2017 07:10:03 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id x126sm2767285wme.12.2017.05.26.07.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 07:10:02 -0700 (PDT) Subject: Re: GDB 7.99.91 MinGW compilation error in cli-script.c To: Eli Zaretskii References: <83fug35v70.fsf@gnu.org> <83y3tt2ow0.fsf@gnu.org> <83vaox2j0w.fsf@gnu.org> <7017128a-7b51-5436-657b-58807d04eb02@redhat.com> <83vaouns1q.fsf@gnu.org> <837f18ohr2.fsf@gnu.org> <54594002-5d70-9ff8-c481-0cbfc8c68c7b@redhat.com> <834lwam7n4.fsf@gnu.org> <20170524193716.5arjibe4s5efvgj7@adacore.com> <15568468-0852-d786-8777-4adbd16825a0@redhat.com> <83tw48jc0f.fsf@gnu.org> <209349d7-a2b5-74ab-3b49-553d6e9ed97e@redhat.com> <83h907kbyg.fsf@gnu.org> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <85877f9a-707d-dd19-f287-5fb1db3bc783@redhat.com> Date: Fri, 26 May 2017 14:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <83h907kbyg.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00562.txt.bz2 On 05/26/2017 02:02 PM, Eli Zaretskii wrote: >> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Fri, 26 May 2017 11:54:03 +0100 >> >>> The code says std::to_string, though. So it sounds like some coding >>> conventions are being applied here of which I wasn't aware, and >>> neither is Emacs. Are these conventions described somewhere? >> >> Just the standard GNU conventions. The code is defining a new >> function template called gdb::to_string. Simplified: >> >> namespace gdb { >> template std::string to_string (const T &val); >> } >> >> There are two implementations of that, one for mingw, written >> as a new function template in place. And another which is >> importing std::to_string into the gdb namespace. But whatever >> the implementations, it's implementation detail of gdb::to_string. > > So the convention is to include the full qualifier of every method? > Including the namespace of the class? Does that include the whole > chain of namespaces up to the root? If not, where does one stop? I admit that I'm puzzled about you having an issue with gdb::to_string, when your original entry said "(std::to_string)", not "(to_string)". I think the convention is to provide enough qualifiers to to make it convenient to search/see what function was changed. For class methods, I think we should include the class name, otherwise it can get ambiguous. I'm fine with not mentioning the namespace when otherwise it's obvious or redundant. E.g., if all of gdb was in namespace gdb [it's not], it'd probably not make much sense to keep putting "gdb::" everywhere. But when referring to a symbol outside gdb's namespace, I'd think it wise to mention the namespace, so that it's clearer what the entry is referring to. > >>> but once again, the convention to put the >>> fully-qualified symbol name in the log entry should be documented, if >>> it isn't already, because Emacs doesn't do that, at least not by >>> default. >> >> I can't see how what Emacs does has any bearing here, since AFAIK, >> Emacs isn't written in C++. > > I use Emacs commands, such as "C-x 4 a", to generate ChangeLog > entries. Don't you do the same? Emacs add-log commands strip the > class and namespace qualifiers. Ah, I thought you were talking about your experience as emacs maintainer. Sorry. I never managed to get used to using emacs commands to write the ChangeLog. I write ChangeLog entries manually, directly in the git commit log, while scrolling through the diff, as last "self review" event, and then copy over to the ChangeLog file at push time. Thanks, Pedro Alves