4 ms·
The guidelines say to use class when there is an invariant and struct otherwise. This is counter productive because if a struct without invariants suddenly gain
by jzwinck 9y ago
The guidelines say to use class when there is an invariant and struct otherwise. This is counter productive because if a struct without invariants suddenly gains an invariant, it should be changed to class. Which doesn't matter except that all forward declarations now also must change (despite years of more permissive compilers allowing a forward declaration of a class later defined as a struct, this is not standard).
Better to always use struct and never class, or the opposite. Always class is simpler because the first members declared in most classes are public, and struct saves you typing "public:" at the top of every class. But always class has the advantage that it is far more popular in C++ library code...including std::array which has no invariants.
- FungalRaincloud 9y agoI can't think of a case where that's not just a quick find/replace to fix. Or, if you're using a more modern IDE, a refactoring rule. Do you have something in mind that might be more complicated?
- bluGill 9y agoI write a library that is used by many downstream projects. If I make the struct->class change in my code all my users who have predeclared my class have to fix their code. They probably won't read release notes, and might be using a permissive compiler (gcc is, clang is not - at least in my experience) so it can be a long time before they get weird bugs reports, which take them time to understand.
- makecheck 9y agoThat’s one of the reasons why “forward headers” are a much better pattern than manually declaring things everywhere. One person saying “struct X;” and another saying “class X;” is a compiler error when the inconsistency is found, and it gets worse when namespaces change, etc. Just push the maintainer to handle this (e.g. <iosfwd>).