On 6/28/19 10:59 AM, Jeff Law wrote:
On 6/28/19 8:55 AM, Martin Sebor wrote:
On 5/28/19 10:31 AM, Martin Sebor wrote:
On 5/28/19 4:24 AM, Martin Liška wrote:
On 5/28/19 11:31 AM, David CARLIER wrote:
Hi,

Here a tiny patch to fix few build warnings.

Kind regards.


Hi.

Well, I see a lot of these struct/class discrepancies when building
GCC with LLVM.
Question is whether it worth changing?

I think it's nice for these to be spelled consistently and no benefit
to mixing and matching them.  If it cleans up common warnings I see
no reason not to make the change.

FWIW, it's also a common convention to use struct for PODs and class
for types with user-defined ctors, and even if GCC doesn't subscribe
to it, make a change in support of it is an improvement independent
of the Visual C++ warning.  (As might be adding such a warning to
GCC to help enforce the convention on projects that do follow it.)

Jeff reminded me in a code review the other day that GCC does
have a guideline for defining POD structs with the keyword
"struct" and classes with ctors/dtors using "class":

   https://gcc.gnu.org/codingconventions.html#Struct_Use

I quickly prototyped a warning to see how closely GCC follows
this convention.  The result shows that out of just under 800
structs and classes defined in GCC sources some 200 use
the keyword 'struct' despite having a ctor or dtor, or about
25%.  So as is the case with most other conventions, without
a tool to help remind us they exist they are unlikely to be
followed with enough consistency to be worth putting in place
to begin with.
This kind of response just makes you look combative.  We have a
convention and we should follow it.  Please do so for your code.

I was responding to myself and adding support to what I suggested
earlier: to add such a warning to GCC to help enforce the convention
on projects that follow it, including GCC.


If we can cleanly implement this kind of diagnostic, then I would
certainly suggest we do so, fix our codebase and turn it on by default
for GCC builds, regardless of its status in -Wall.

I'd be happy to finish and submit the warning when I'm done with
the work whose review prompted me to implement it.

Martin

Reply via email to