From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13224 invoked by alias); 12 Jul 2019 11:42:17 -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 13210 invoked by uid 89); 12 Jul 2019 11:42:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:2274, Google 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; Fri, 12 Jul 2019 11:42:15 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C1192F8BD2; Fri, 12 Jul 2019 11:42:14 +0000 (UTC) Received: from localhost (unknown [10.33.36.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0DD3D1001B12; Fri, 12 Jul 2019 11:42:13 +0000 (UTC) Date: Fri, 12 Jul 2019 11:44:00 -0000 From: Jonathan Wakely To: Jakub Jelinek Cc: Martin Sebor , Jason Merrill , Nathan Sidwell , Richard Biener , gcc-patches Subject: Re: [PATCH 0/3] add support for POD struct convention (PR 61339) Message-ID: <20190712114213.GK4665@redhat.com> References: <20190712082408.GX2125@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190712082408.GX2125@tucnak> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-07/txt/msg00968.txt.bz2 On 12/07/19 10:24 +0200, Jakub Jelinek wrote: >On Mon, Jul 08, 2019 at 03:56:51PM -0600, Martin Sebor wrote: >> A couple of GCC's Coding Conventions call to >> >> 1) Use the struct keyword for plain old data (POD) types. >> https://www.gnu.org/software/gcc/codingrationale.html#struct >> >> and >> >> 2) Use the class keyword for non-POD types. >> https://www.gnu.org/software/gcc/codingconventions.html#Class_Use > >This is a coding convention that has been added without any discussion >whatsoever on that, maybe it was some Google internal coding convention or >something, do we really want to enforce it rather than discuss >and decide what we actually want? > >With my limited C++ knowledge, the main distinction between struct and class >when both can appear interchangeably is that struct defaults to public: The default applies to class members and base classes, but that's the *only* distinction. >and class defaults to private:, and I think it is best to use those that >way, rather than having tons of class ... { public: ... } everywhere. > >There are many C++ class boolean properties, rather than just >POD vs. non-POD and we could pick any of them instead of this particular one >for the struct vs. class distinction if we wanted to enforce it, but why? I'm also unconvinced that POD is a useful distinction. A class might be a POD today, but then we decide to add a default constructor to it (or if/when we move to C++11, add default member initializers to it). Does that mean we need to replace struct with class to follow this convention? Or we might decide to add a std::string member to it, which stops it being a POD. Should every reference to it be changed from struct to class? Personally I think "no user-defined constructors" might be a more useful distinction than POD. This is not a POD (because of the std::string member) but I don't see why it should be a class not a struct: struct A { std::string name; int id; }; >I'd just arrange that when being compiled with clang we compile with >-Wno-mismatched-tags to get rid of their misdesigned warning and not add >such misdesigned warning to GCC, that will just help people spread this >weirdo requirement further. > > Jakub