From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27161 invoked by alias); 27 Nov 2018 12:50:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27141 invoked by uid 89); 27 Nov 2018 12:50:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:html=c2, Hx-languages-length:2577, HContent-Transfer-Encoding:8bit?= X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Nov 2018 12:50:47 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6A75BAF0D; Tue, 27 Nov 2018 12:50:45 +0000 (UTC) Subject: Re: [PATCH/coding style] clarify pointers and operators To: Martin Sebor , Gcc Patch List References: <6bce0b3a-0b0d-f03f-5f92-e00156e63629@gmail.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Tue, 27 Nov 2018 12:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <6bce0b3a-0b0d-f03f-5f92-e00156e63629@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg02176.txt.bz2 On 11/26/18 6:59 PM, Martin Sebor wrote: > Martin suggested we update the Coding Conventions to describe > the expected style for function declarations with a pointer > return types, and for overloaded operators.  Below is the patch. > > As an aside, regarding the space convention in casts: a crude > grep search yields about 10,000 instances of the "(type)x" kinds > of casts in GCC sources and 40,000 of the preferred "(type) x" > style with the space.  That's a consistency of only 80%.  Is > it worth documenting a preference for a convention that's so > inconsistently followed? > > Martin > > Index: htdocs/codingconventions.html > =================================================================== > RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v > retrieving revision 1.85 > diff -u -r1.85 codingconventions.html > --- htdocs/codingconventions.html    30 Sep 2018 14:38:46 -0000    1.85 > +++ htdocs/codingconventions.html    26 Nov 2018 17:59:21 -0000 > @@ -803,12 +803,17 @@ >    - x >   >    cast > -  (foo) x > -  (foo)x > +  (type) x > +  (type)x >   > -  pointer dereference > -  *x > -  * x > +  pointer cast > +  (type *) x > +  (type*)x > + > + > +  pointer return type > +  type *f (void) > +  type* f (void) >   >   > > @@ -992,6 +997,21 @@ >  Rationale and Discussion >  

> > +

> +Note: in declarations of operator functions or in invocations of > +such functions that involve the keyword operator > +the full name of the operator should be considered as including > +the keyword with no spaces in between the keyowrd and the operator > +token.  Thus, the expected format of a declaration of an operator > +is

> +    T &operator== (const T & const T &);
> +
> +and not for example
> +    T &operator == (const T & const T &);
> +
> +(with the space between operator and ==). > +

> + > >  

Default Arguments

> Thank you Martin for the patch, I like it. Martin