This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/3] add support for POD struct convention (PR 61339)

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.


  2) Use the class keyword for non-POD types.

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

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

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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]