Boost logo

Boost :

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!


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk