|
Boost : |
From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-01-08 19:29:08
Dan W. wrote:
> Daniel Wallin wrote:
>
>> Dan W. wrote:
>>
>>> It's been suggested to me that introducing inheritance and
>>> virtual functions via inheritance in debug mode might not be
>>> good ideas. Note however that,
>>> (A) as of version 1.01 there is no longer size augmentation
>>> via inheritance, since the only data member was removed.
>>
>>
>> Yes there is, there's still a virtual member function.
>
>
> I meant no "size augmentation" in the sense of sizeof(a_class) being
> different from sizeof("a_class : invariants< a_class >").
If sizeof("a_class : invariants< a_class >") means sizeof(a_class when
derived from invariants<a_class>) then yes, the size still differs
because of the virtual function.
>>> <snip>
>>> (E) Using inheritance allows one to use succint class member
>>> names in the invariant assertions, rather than have to
>>> dereference a pointer, or reference via '.'.
>>
>>
>> From my implementation:
>>
>> <snip>
>> I don't see how it's related to inheritance. Or did you mean something
>> else?
>
>
> I must have meant something else, since I don't understand what you're
> trying to tell me.
> What I say in (E), if that's what you're not sure what I mean, is that if
>
> class my_class
> {
> int a, b, c;
> struct check_invariants
> {
> void check( my_class const & );
> };
> friend class check_invariants;
> };
>
> then I need to de-reference members when writing assertions...
>
> void my_class::check_invariants::check( my_class const & _ )
> {
> assert( _.a + _.b == _.c );
> }
>
> I find it more intuitive for check() to be a member function.
Again, this has nothing to do with inheritance. check_invariants() can
be a member function regardless if my_class is derived from invariants<>
or not. Like this in the code I posted:
class my_class
{
int a, b, c;
friend class invariant_access;
void invariant() const
{
assert(a + b == c);
}
};
-- Daniel Wallin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk