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