From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37595 invoked by alias); 1 Sep 2016 18:48:27 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 36700 invoked by uid 89); 1 Sep 2016 18:48:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=prefers, fight 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, 01 Sep 2016 18:48:25 +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 5DA617F7A9; Thu, 1 Sep 2016 18:48:23 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u81ImMoD002963; Thu, 1 Sep 2016 14:48:22 -0400 Subject: Re: Go C++ only To: Simon Marchi References: <212bc30a-e6ad-886b-0881-8206dd91b933@redhat.com> <410fa84696e520ca3845c841fc7391b8@simark.ca> <5479c5a0-a346-1718-5573-eeb4b19bc9db@redhat.com> <72276a8218ef0e667097dc3fb152c518@simark.ca> Cc: gdb@sourceware.org From: Pedro Alves Message-ID: <66f41b49-f794-47de-65ff-1f1c0f69ff75@redhat.com> Date: Thu, 01 Sep 2016 18:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <72276a8218ef0e667097dc3fb152c518@simark.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00010.txt.bz2 On 09/01/2016 07:33 PM, Simon Marchi wrote: > On 2016-09-01 14:22, Pedro Alves wrote: >>> Perhaps some precisions about the coding style, for C++-specific >>> constructs (e.g. initializer lists). >> >> List initialization is C++11, so it's out, at least for now. > > Oh, I meant the list of members to initialize in a constructor (the list > after the colon), that's not C++11 I believe. I see it's all discussed > in the gcc coding convention page. Ah, whooops, sorry. So that's I think the one detail that if you look at gcc's code, you'll notice that in practice it deviates a little from what the docs say. Most of the gcc code I looked at I think simply follows what emacs with "c-set-style gnu" prefers, which is to indent the initializer list by a couple spaces. Some random examples: class pass_parallelize_loops : public gimple_opt_pass { public: pass_parallelize_loops (gcc::context *ctxt) : gimple_opt_pass (pass_data_parallelize_loops, ctxt), oacc_kernels_p (false) {} [...] class example_base { public: example_base () : m_kind (0), m_a (ggc_cleared_alloc ()) {} [...] bit_field_mode_iterator ::bit_field_mode_iterator (HOST_WIDE_INT bitsize, HOST_WIDE_INT bitpos, HOST_WIDE_INT bitregion_start, HOST_WIDE_INT bitregion_end, unsigned int align, bool volatilep) : m_mode (GET_CLASS_NARROWEST_MODE (MODE_INT)), m_bitsize (bitsize), m_bitpos (bitpos), m_bitregion_start (bitregion_start), m_bitregion_end (bitregion_end), m_align (align), m_volatilep (volatilep), m_count (0) { While their docs say: "(...) place the colon of the initializer clause at the beginning of a line. gnuclass::gnuclass () : base1 (), base2 (), member1 (), member2 (), member3 (), member4 () { ... }; I think that we should this a documentation bug, and that it's better to follow gcc's _actual_ style in practice. Why fight against emacs, right? :-) Thanks, Pedro Alves