C++Talk.NET

George Ryan · Guest

Hello,

I have posted some code below that shows using the NVI idiom to more
cleanly have virtual behaviour within an inherited interface. However,
I have run into a problem I don't know how to solve in relation to
inheriting the invariants. I would like to weaken the precondition,
but the add() function in the base class is the entity actually
applying the precondition, so I don't have the ability to short circut
it as I want to.

I've considered:

1. Moving the pre and post conditions into the do_add() function. This
means that everyone inheriting the class would be on their honour to
call the pre and post conditions, in addition to any others they may
add.

2. Making the pre and post condition functions virtual as well, but
this just seems like a variant of #1, providing an opportunity for the
user to mistakenly mess up the invariant checking by forcing them to
rewrite the original.

Can anyone suggest a good/better way to handle this condition? Are
invariants orthogonal to the inheritence model in C++?

Thank you,
George

---- START ----

class invariant {
public:
void add( const int& i )
{
precondition( i );
do_add( i );
postcondition( i );
}

protected:
virtual void do_add( const int& i )
{
try {
list_.push_back( i );
}
catch ( const std::exception& e )
{
// some sort of error must have occured.
}
}

// Precondition: i must not already be in the list
void precondition( const int& i )
{
if ( find( list_.begin(), list_.end(), i ) != list_.end() ) {
throw 0;
}
}

// Postcondition: i must be in the list
void postcondition( const int& i )
{
if ( find( list_.begin(), list_.end(), i ) == list_.end() ) {
throw 0;
}
}

list<int> list_;
};

class inherited : public invariant {
protected:
// Would like to weaken the precondition here
// so that an exception is _not_ thrown when
// i is already in the list, just no-op.
virtual void do_add( const int& i )
{
// Would LIKE to simply return if i is already in
// the list, but I can't because precondition() has
// already been called.

// do a bunch of other stuff or add
// i to list another way
}
};

---- END ----

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Tokyo Tomy · Guest

[email]gwryan (AT) accesswave (DOT) ca[/email] (George Ryan) wrote in message news:<d871bbf3.0408121529.115a7ec9 (AT) posting (DOT) google.com>...

kanze@gabi-soft.fr · Guest

[email]gwryan (AT) accesswave (DOT) ca[/email] (George Ryan) wrote in message
news:<d871bbf3.0408121529.115a7ec9 (AT) posting (DOT) google.com>...

John Sheehan · Guest

I think the reason you are running into problems is because you are
trying to weaken the precondition. Given your design, that is not
really possible. You have a couple of options:

1.) As you mentioned, you could make the pre / post conditions
virtual. This would allow you to override either one's functionality,
if desired. This would allow you to strengthen or weaken the pre /
post conditions as needed. I'm not a big fan of this, as your base
class is serving multiple purposes, namely defining the calling
template as well as one default implementation. I'm not sure these
particular pre / post conditions deserve the special status, but maybe
they do for your application.

2.) Define a template that accepts the pre / post coditions as well
as the actual worker class. This has the advantage of keeping
separate choices orthogonal. You could then define a bunch of
different pre / post conditions that you could choose from, depending
upon your needs. You could also design it so that it ends up defining
a separate base type, depending upon the combination of pre / post
conditions chosen. I think this is a good idea, since the code that
is using the actual implementation should be written knowing what the
invariants are. Changing those invariants through some form of
virtual function implementation runs the risk of breaking the client
code.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]