Re: operator== for aggregate types / member wise comparison
"Seungbeom Kim" <musiphil@bawi.org>
Balog Pal wrote:
This "problem" is a top gotcha for ~ 2 decades. And has an extremely
easy solution: do NOT write copyctor, op=. I mean it. Not in user code!
[...]
My experience is to just have two basic cases in user code: forbid cctor
and
op= or leave the auto-created. Exceptions are in the 'writing library'
land, where it is increasingly hard to find a case of a new resource or
collection not already covered.
Suppose you want to do something *in addition to* the default behaviour,
such as logging:
Heh, supposing is a good thing -- in moderation. But we;d better stick to
reality.
Copy ctor and op= anre not just "usual functions", they are special ones
with predetermined semantics. With the purpose to create a copy. So you
better not want to do anything beyond that in those finctions. Especially
as the compiler has license to omit them in certain situations, so the
addition may just be skipped.
What is the problem with putting the extra stuff in a properly named
function fuch as LoggedCopy() ;-)
class Big
{
// lots of members
public:
Big(const Big&);
};
Big::Big(const Big& other)
: first(other.first)
, second(other.second)
, third(other.third)
// and so on
{
std::clog << "Big(" << this << ")::Big(const Big& = @"
<< &other << "):\n";
std::clog << "\tfirst=" << first << ", second=" << second
<< ", third=" << third << std::endl;
}
How would you solve this problem?
By elimination.
(If you tell me some realistic example, I may give actual hints...
'general' problem solving is not the way of programming. )
Really, I used traces time-to-time, but not in said functions -- a LOG has
its use, but not on this technical level. {Unless, maybe if you have an
utter mess -- but it is likely an outcome of such ideas. }
I have had more than a case where I had to introduce a user-defined
copy constructor and enumerate all members just to do such a logging.
Okay, then you can tell the purpose and usefulness of why it was good, and
what that log was used for. I am really curious.
And well, if there is an absolute need, then you go and maintain the list of
members. No hunters - no hens, we don't have the perfect world. But a
language needs no tuning or support for some extreme cases.
Btw if it's enough to drop a line in the log, it can be done using a
stateless member.
If just for instrumentation, I (likely) could create one that could call the
enclosing class's Dump function too, so if placed properly at the end of the
host, can do what you did above. (just from top of my head)
class Big;
template <class T>
struct LogTweak {
static void Log(const T * host);
const T * GetHostAddr() const;
LogTweak() { Log(GetHostAddr());}
LogTweak(const LogTweak &) { Log(GetHostAddr());}
};
class Big
{
public:
string State2String() { ... }
private:
// must be last member
LogTweak<Big> last;
};
Log() calls the host's renderer, no problem here.
GetHostAddr() is the tricky part, but with some ugly trick and casts the
address can be figured, having Big b; ptrdiff (char *) &b.last - (char *)
&b; then using that offset substracted from this. the offsetof macro is
POD-only, but i'm sure there are general solutions providin it as
compile-time constant (and even the stock one shall work in practice for
regular members).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]