From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85364 invoked by alias); 26 Nov 2018 17:59:53 -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 85355 invoked by uid 89); 26 Nov 2018 17:59:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=40000, 40,000, 10,000, crude X-HELO: mail-qk1-f169.google.com Received: from mail-qk1-f169.google.com (HELO mail-qk1-f169.google.com) (209.85.222.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Nov 2018 17:59:51 +0000 Received: by mail-qk1-f169.google.com with SMTP id y16so12840152qki.7 for ; Mon, 26 Nov 2018 09:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=tbjeVEx6EufRBlwDqJ8ZIwJf/pRT5rog0EoFbicDQgw=; b=m1AbWmWNOyIrp+KH4mFqyuNwWZdQ+pAsuxt3mHP/dBwBXy73Q25Uq901ysVuNoU+0d Qu3PhAqnQDCjgDOU+vr05EOQaHJnzg2kZxANa/kc5YbJZ2wovE0A7ROaiYMMxbTrkbDs WJ8LK3CVh32KtIe2FTGCtMXaSeTV7M3PlIzYHrU3O1joCBgcXE0GyQSdgFdw55Etr6Zd LnZZdidegTvrsENJ5juDlY4pv+YYFptiedVfq0EB/WvQb9TYKyH7qdaZqlTfXj2mI8Oe UURx2WBspbcAYenMO82yRsLn3s/xu8SiO/MgLWrlPigFdByU8LQ1PB2CXrmfyvm2rmHk 7fLg== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id k62sm427422qte.86.2018.11.26.09.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 09:59:49 -0800 (PST) To: Gcc Patch List , =?UTF-8?Q?Martin_Li=c5=a1ka?= From: Martin Sebor Subject: [PATCH/coding style] clarify pointers and operators Message-ID: <6bce0b3a-0b0d-f03f-5f92-e00156e63629@gmail.com> Date: Mon, 26 Nov 2018 17:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg02101.txt.bz2 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