On 7/22/19 4:19 PM, Jeff Law wrote:
On 7/8/19 3:58 PM, Martin Sebor wrote:
The attached patch implements three new warnings:
* -Wstruct-not-pod triggers for struct definitions that are not
POD structs,
* -Wclass-is-pod triggers for class definitions that satisfy
the requirements on POD structs, and
* -Wmismatched-tags that triggers for class and struct declarations
with class-key that doesn't match either their definition or
the first declaration (if no definition is provided).
The implementation of -Wclass-is-pod and -Wstruct-not-pod is fairly
straightforward but the -Wmismatched-tags solution is slightly unusual.
It collects struct and class declarations first and diagnoses mismatches
only after the whole tramslation unit has been processed. This is so
that the definition of a class can guide which declarations to diagnose
no matter which come first.
So there was some discussion on whether or not we even wanted to keep
the struct vs class convention for GCC.
Did that reach any kind of conclusion? I don't have a strong opinion
here and will adjust to whatever the consensus is.
I'm not really sure how to gauge consensus here but this patch doesn't
actually enforce the GCC convention, it just makes it possible (none
of the new options is included in -Wall or -Wextra; they all have to
be enabled explicitly).
I myself wouldn't adopt a class/struct convention like that if given
the choice and wouldn't be at all upset if we dropped it going forward,
despite all the effort I put into the cleanup (which has already been
committed). But us dropping it won't affect other projects that also
use it(*), albeit without enforcement, and so I would rather not tie
the consideration of the patch to the GCC guideline. I would think
helping other projects enforce it if they find it helpful would be
seen as valuable even if we don't find the convention useful in GCC
anymore.
The struct/class convention aside, and ignoring the Visual C++ bug
that likely gave rise to it, the -Wmismatched-tags option is useful
for all projects that value consistency: declaring struct using
the same class-key everywhere, and same for classes.
Martin
PS The top-rated answer to the article below gives some idea of how
popular this struct/class rule of thumb might be out there:
https://stackoverflow.com/questions/54585
Incidentally, among the many hits I get when searching for struct
vs class online are guidelines to prefer one over the other due
to better interoperability, efficiency, or expressiveness in some
languages that do make more of a distinction between the two than
C++ does (e.g., C#, D, Ruby, or Swift). I can see mixed language
projects or users coming to C++ from those other languages wanting
to use a convention in C++ that reflects the use of the two keywords
in those other languages even if the use doesn't actually have
the same effect.
