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