On 12/07/19 09:14 -0600, Martin Sebor wrote:
On 7/12/19 5:42 AM, Jonathan Wakely wrote:
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?
Right, that's a downside of such a convention. It can be mitigated
(but not avoided completely) by eschewing the class-key in references
to the type if it's unambiguous.
Well IMO the class-key should never be used except in declarations of
the type. I dislike seeing 'struct X x = { ... };' in C++ because the
'struct' is superfluous. I prefer to avoid naming ambiguities that
require the 'struct' there (e.g. stat(3) and struct stat). If GCC has
any structs that are using the same name as a function I'd suggest
renaming the struct or the function :-)
So the only time you should have 'struct X' is when declaring it
(including in its definition). And for that case being consistent to
silence -Wmismatched-tags is enough (and while not technically
necessary, it's also harmless to be consistent).
