From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11810 invoked by alias); 23 Feb 2017 14:49:57 -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 10449 invoked by uid 89); 23 Feb 2017 14:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,LIKELY_SPAM_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=whiles, while"s, Hx-languages-length:2290 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, 23 Feb 2017 14:49:54 +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 743568046A; Thu, 23 Feb 2017 14:49:54 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1NEnqio014200; Thu, 23 Feb 2017 09:49:53 -0500 Subject: Re: [PATCH v1.1 1/3] Introduce gdb::function_view To: Yao Qi References: <1487775033-32699-1-git-send-email-palves@redhat.com> <1487775033-32699-2-git-send-email-palves@redhat.com> <8636f39b5e1e2cbdeabbf8dfd999e709@polymtl.ca> <4c8528d8-0115-3bf3-0a16-42f44be580a9@redhat.com> <20baebcd-0f6a-89ca-ef34-503795171d43@redhat.com> <20170222221158.hqfnyyvyqqxetygk@localhost> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 23 Feb 2017 14:49: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: <20170222221158.hqfnyyvyqqxetygk@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00622.txt.bz2 On 02/22/2017 10:11 PM, Yao Qi wrote: > Double "a" at the end. > > Double "while"s. Thanks, fixed. > >> +namespace gdb { >> + > > This is a new namespace in gdb source. What is the rule of using this > namespace? I don't have a hard rule predetermined. I originally put the C++03 unique_ptr shim under the gdb namespace to make it clear at the call sites that that was not the std type, but gdb's replacement. I.e., gdb::unique_ptr vs std::unique_ptr. Since then, gdb::unique_ptr is gone, but gdb::unique_xmalloc_ptr remains, and we've been putting these generic library-like utilities under the namespace: common/function-view.h:154:namespace gdb { common/function-view.h:353:} /* namespace gdb */ common/gdb_unlinker.h:23:namespace gdb common/gdb_unique_ptr.h:25:namespace gdb common/gdb_unique_ptr.h:43:} /* namespace gdb */ common/gdb_optional.h:23:namespace gdb common/gdb_ref_ptr.h:25:namespace gdb I think putting these new things in _some_ namespace is the right thing to do. gdb is just the no-brainer namespace name. IMO, _all_ of GDB should be under "namespace gdb". Then these utilities would either be put in "namespace gdb" too, or in a "namespace gtl", for "gdb template library" or something like that. Or we could put them under "gtl" already. I have a series that put the whole of gdb under namespace gdb: https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace I wrote that while experimenting with ways to use gnulib's C++ namespace mode, in order to avoid the "#define open rpl_open" defines gnulib does... I nowadays believe the put-gdb-in-a-namespace approach is the best one. However, when we put gdb under a namespace, debugging GDB itself becomes a bit harder, since you then have to do "b gdb::some_function" instead of "b some_function". This is just dogfooding pain, of course, users run into this too... That's what led to me to work on this branch: https://github.com/palves/gdb/commits/palves/cp-linespec-2 with that, "b some_function" sets breakpoints on all functions/methods named some_function in all namespaces. And it was testing that branch with --target_board=dwarf4-gdb-index that led to the bug fixed by this series... It's a never ending story... :-) Thanks, Pedro Alves