Re: operator== for aggregate types / member wise comparison
"Martin T." <0xCDCDCDCD@gmx.at>
Now, what is the percentage of classes/structs in a project that has a
And then, where it is based on full memberwise comparition?
Guess if you find the special case, it will not change members all that
The use case for these structs is representing configuration data. As
such there are quite a few of them and I *do* expect them to change
Sure, I use configs, and indeed members come and go. I still can't recall a
case to want op == on the whole config. I read it at some place, possibly
write it out as a bulk, and use individual members... but how comparision
For these items memberwise equality is exactly
appropriate most of the time.
It could 'work' indeed but for what situation?
(btw I'd guess Boost has tools for such beasts -- tuple, any, ... if plain
old struct is not enough)
Someone will forget to add to the operator== *especially* if it's only
used in the unit tests.
Well, if it only used in UT, it is a good indication of unwanted ballast
that has nothing to do in the real interface. The test should not be that
intrusive. And if, for implementation of the harness it needs compare that
way -- I really would go with the earlier suggest: code generator.
The workaround I currently use to safeguard against this is:
1.) operator== is defined in the header
2.) Manually added static assert on the size of the struct
inline bool operator==(Cfgdata const& lhs, Cfgdata const& rhs)
BOOST_STATIC_ASSERT(sizeof(Cfgdata) == 56); // Check size, so we don't
forget to add new members!
Interesting idea really. My first line of thought would be 'scrap it'.
OTOH I do have situations with similar maintain cases -- the 'offending'
functions are mostly I/O routines (like stream op << >> ), and when adding a
member I follow the ritual to pick another member and look visit all
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]