From: Dan W. (danw_at_[hidden])
Date: 2004-01-10 21:52:59
Daniel Wallin wrote:
>> I filed a bug report. As for the macro, it was kind of needed anyways.
> Really? I'm referring to the INVARIANTS() macro, which wasn't needed in
> my code.
True, nor does my code really 'need' the macro...
#define INVARIANTS( name ) \
private: \
typedef name THIS_TYPE_NAME; \
friend struct \
boost::DBC::EEICHK< name >; \
void CHECK_INVARIANTS() const
...but I think it's kind of convenient. You have a friend function,
which you correctly declare private; but if a user forgets to make it
private it might cause hard to track problems. With the macro I'm
forcing private, which might cause members below it to become private;
but this shouldn't be as hard to debug. What the problem with my
compiler necessitates is the typedef, which in turn necessitates the
name of the class as argument. Nothing I can do about it at the moment,
as changing compilers is not an option for me. Long story.
Anyways, I think you have the same bug I have: A derived class can
change its embedded base class' protected members or call its protected
functions without causing base::check_invariants() to be called. I think
that the solution is to make sure that a call of check_invariants in a
derived class always implies a call of check_invariants in the base
class or classes. Not sure how I'm gonna tackle this one...
Cheers!