Redeclarig the unimplemented base pure virtual methods

[qazmlp]

I have a base class('base') containing 10 public pure virtual
menthods.
I have a class(derivedOne) deriving from 'base'. derivedOne implements
only 7 of those base methods. Now, is it a good style for derivedOne
to explicitly declare the other 3 as pure virtual methods?

 

[John Harrison]

I have a base class('base') containing 10 public pure virtual
menthods.
I have a class(derivedOne) deriving from 'base'. derivedOne implements
only 7 of those base methods. Now, is it a good style for derivedOne
to explicitly declare the other 3 as pure virtual methods?

I think not. I think the way to look at this is to ask what you are trying
to achieve and how can it be maintained as code evolves.

I assume you are trying to achieve a complete list of virtual functions in
derivedOne. But consider, suppose a new pure virtual function was added to
base. Would you remember to add it to derivedOne? Would the compiler tell
you to add it? I think the answer to both these questions is no. Even worse
suppose a pure virtual was removed from base. Would you remember to remove
it from derivedOne? If you don't then you have a derivedOne introducing a
pure virtual where previously it only inherited them.

john

 

[David Harmon]

I have a class(derivedOne) deriving from 'base'. derivedOne implements
only 7 of those base methods. Now, is it a good style for derivedOne
to explicitly declare the other 3 as pure virtual methods?

No, it's a terrible idea. You should use the base class methods, or
implement them compatibly in the derived class. If that's impossible,
then the class isn't a proper subtype.

A derived type should never demand more or deliver less than the base
type.

Google for "Liskov Substitution Principle" or see
http://www.objectmentor.com/resources/articles/lsp.pdf

 

[Cy Edmunds]

No, it's a terrible idea. You should use the base class methods, or
implement them compatibly in the derived class. If that's impossible,
then the class isn't a proper subtype.

A derived type should never demand more or deliver less than the base
type.

Google for "Liskov Substitution Principle" or see
http://www.objectmentor.com/resources/articles/lsp.pdf

One of us doesn't understand the OP's post. I take it to mean (using an
example with fewer virtual functions):

class IThing
{
public:
virtual const std::string &name() const = 0;
virtual void op() = 0;
virtual ~IThing() {}
};

// partial implementation of IThing
class BThing : public IThing
{
private:
std::string m_name;
public:
BThing(const std::string &i_name) : m_name(i_name) {}
virtual const std::string &name() const {return m_name;}
virtual void op() = 0; // good style?
};

Anyway, I would say it is NOT good style because it appears you are
introducing a new function when you are not. However I wouldn't call it a
major mistake by any means.

Sometimes in this situation I list the unimplemented functions in comments,
but that can lead to maintainability issues (e.g. if I change the function I
have to make a parallel change in the comment).

 

[David Harmon]

One of us doesn't understand the OP's post.

OK, it was me. I missed that the base class function was pure virtual.

Anyway, I would say it is NOT good style because it appears you are
introducing a new function when you are not. However I wouldn't call it a
major mistake by any means.

Why would you ever do that? If it's pure virtual in the base class you
do not have to declare it pure virtual in the derived. It's inherited.
That's what threw me in the post. You never replicate stuff in derived
classes that you inherit from the base - it's already there. If you try
to put things in two places, all you do is create an opportunity for
them to get out of sync.