From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121454 invoked by alias); 30 Nov 2016 18:16:28 -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 121431 invoked by uid 89); 30 Nov 2016 18:16:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Wed, 30 Nov 2016 18:16:26 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 9CC2F64DA2; Wed, 30 Nov 2016 18:16:25 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUIGOF9011973; Wed, 30 Nov 2016 13:16:24 -0500 Subject: Re: [PATCH 1/2] Add unit test to aarch64 prologue analyzer To: Yao Qi , Antoine Tremblay References: <1480428758-2481-1-git-send-email-yao.qi@linaro.org> <20161130111459.GG22209@E107787-LIN> <20161130163449.GI22209@E107787-LIN> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <911a9b62-5be4-f026-4bd6-c24a742a561a@redhat.com> Date: Wed, 30 Nov 2016 18:16: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: <20161130163449.GI22209@E107787-LIN> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg01007.txt.bz2 On 11/30/2016 04:34 PM, Yao Qi wrote: > On Wed, Nov 30, 2016 at 06:53:08AM -0500, Antoine Tremblay wrote: >>>> Also I wonder if we need to specify the default constructor explicitly ? >>>> Is there a rationale for it? >>>> >>>> It's never used too, unless you apply my previous comment. >>> >>> The instruction_reader_test default constructor is never used. How >>> about using "= delete"? >>> >>> instruction_reader_test () = delete; >>> instruction_reader_test (std::initializer_list init) >>> : insns{init} {} >> >> Yes that would be more appropriate if we're going to specify that. >> >> I just wrote a patch with a C++ class and did not include explicit >> default constructors do you think we should make it a code convention to >> explicitly specify their existence or non-existence (=default, =delete) ? > > If you don't want default constructor to be used, "=delete" is useful, > IMO, which tells compiler not to generate the default constructor. The > intention is quite clear that I don't want you to use the default > constructor. Note that if the class has a user-defined constructor, then the default ctor is not generated at all. So you don't need to delete the default one then. If I see a "=delete" in such case (as above), I'll scratch my head wondering why the redundancy is there in the first place, and maybe if so inclined that day remove the unnecessary code as an obvious cleanup patch. :-) (deleted functions participate in overload resolution, so there's a difference from the method not being defined, but I don't believe that's what you were going for here.) Thanks, Pedro Alves