Re: [lmi] -Wno-mismatched-tags please

[Vadim Zeitlin]

On Fri, 20 May 2016 04:24:17 +0000 Greg Chicares <address@hidden> wrote:

GC>   https://github.com/vadz/lmi/pull/31
GC> | Consistently use either "struct" or "class" in both forward declarations 
of
GC> | the test class and when defining it to avoid clang -Wmismatched-tags 
warning.
GC> 
GC> Not a defect.

 I feel like I spend my (and your...) time disagreeing with you recently,
so please feel free to skip all the rest if you're tired of this and don't
want to discuss this relatively unimportant, but your conclusion seems just
so obviously incorrect to me that I can't prevent myself from arguing about
it.







[spoiler space left to allow you to delete this message without reading it]











GC> For forward declarations and friend declarations, I prefer the more general
GC> key "class": when I write them, I may not yet sure whether I'll define a
GC> class or a struct.

 Sorry, but how is this a good reason to continue doing it like this?
Surely you know what it is before you commit the code, so you could always
modify the header before doing it.

 Although actually my personal recommendation would be to use class in
forward declarations and also use class for defining these types because I
prefer to use struct for simple "records", i.e. "tuples with named fields"
if you wish. Like this seeing whether a type is a struct or a class tells
me something about it. In your use there is no possibility to extract any
kind of information about the type when you see it declared as struct. Yet
you must know that any human reading the code can't prevent from trying to
find a pattern, even if there is none.

GC> There's no good reason to change any of this. See the erratum for pages
GC> 153-154 here:
GC>   http://www.gotw.ca/publications/xc++-errata.htm
GC> | It's perfectly legal and standards-conforming to forward-declare a class
GC> | as a struct and vice versa. In most of the book I've tended to avoid doing
GC> | that, though. Why? Only because some compilers are buggy and still don't
GC> | get this right -- e.g., by name-mangling a class and a struct differently,
GC> | which will cause the linker to fail to match them up. Such compiler bugs
GC> | really are bugs and are wrong, but they're common enough that we might as
GC> | well avoid the issue by not relying on this standard feature. Sigh.
GC> 
GC> C++98 7.1.5.3/6
GC> | the enum keyword shall be used to refer to an enumeration (_dcl.enum_),
GC> | the union class-key shall be used to refer to a union (_class_),
GC> | and either the class or   struct class-key shall be used to refer to a
GC> | class (_class_) declared using the class or struct class-key.
GC> C++98 9/4
GC> | A structure is a class defined with the class-key struct

 This just proves that it's legal, not that it's moral. It's a question of
consistency and while I agree that there is no need to put consistency
above all else, there seems no good reason to be inconsistent here. It's
similar to e.g. "class" and "typename" being both allowed for template
parameters: it's perfectly legal to use either and to use one in one place
and the other one in another. Yet it would be pretty confusing to read

        template <class T> Vector { ... };
        template <typename T> List { ... };

for example as you would inevitably wonder about why is the vector element
a class while a list element any type. Similarly, here, questions
inevitably arise both when reading the code and when writing it as there is
no obviously right example to follow. I did already spend some time
hesitating about this before and I'll probably do it again in the future.

GC> AFAICS, this warning is wrong and the clang developers should remove it.

 I think this warning is not as useful as some others, but that it's
helpful and while I'll disable it for building lmi I definitely like having
it for my other projects as it's an automatic way of enforcing consistency
which is always good.

 Regards,
VZ