Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

OrigamiMan64

private virtual functions

This topic is 5235 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Take a look at the code below and guess what happens
#include <iostream>

class B
{
public:
	virtual void foo (  )
	{
		std::cout << "All your BASE are belong to us.\n";
	}
};

class D : public B
{
private:
	virtual void foo (  )
	{
		std::cout << "What you say!?!?!\n";
	}
};

int main (  )
{
	D d;
	B * pb = &d;

	pb->foo (  );
	return 0;
}
 
The private function is invoked in D. This means that a virtual function of a base class cannot really be hidden by a derived class. This bothers me. Is there any way to protect D''s privates better?

Share this post


Link to post
Share on other sites
Advertisement
That''s exactly what''s supposed to happen. If you didn''t want the derived class to be able to change the behaviour of the virtual function why do you declare it virtual in the first place?

Share this post


Link to post
Share on other sites
ok, more concrete example: I'm making a heirarchy of windows-like controls for the console. my base DosWnd class has two public virtual methods called SetVisible and SetFocused, which are both virtual to allow derived controls to react when these states are changed. I have a control called DosFocusIterator which derives from this. I want to hide the functionality to change the visibility, since a FocusIterator should never be visible, and hide SetFocused, because it itself should never be focused. However, I have no way to truely make those functions inacessable. Perhaps my heirarchy is designed wrong, but thats where my problem is coming from.

[edited by - OrigamiMan64 on May 21, 2004 8:38:46 PM]

Share this post


Link to post
Share on other sites
Your hieararchy just doesn''t make sense. Why is an iterator inheriting from a window? Your inheritence doesn''t seem to be based on is-a relationships.

Share this post


Link to post
Share on other sites
the DosFocusIterator is a ''DosWnd control'' in that it recieves input events from the tree the same way that all other controls do. I could make two base classes, one that supports the input distribution and one that supports the display properties, but I really would prefer to avoid multiple inheritance.

Share this post


Link to post
Share on other sites
Having an invisible control that can''t accept focus that accepts input sounds very strange. What is the purpose/function of the control?

Share this post


Link to post
Share on other sites
You could try a different inheritance structure such as:


class GenericWindowObject
{
private:
virtual void foo() {}
};

class DosWnd : public GenericWindowObject
{
public:
virtual void foo() {}
};

class DosFocusIterator : public GenericWindowObject
{
private:
virtual void foo() {}
};


That way, a DosWnd pointer could access foo() for any of its derived classes, but a GenericWindowObject pointer could NOt access foo() for any of its derived classes, including DosFocusIterator. I still think that you should change your heirarchy, though, because a DosFocusIterator doesn''t quite fit the "is a" contract that it should have with DosWnd.

Share this post


Link to post
Share on other sites
You cannot reduce the accessibility of members declared in a publicly inherited base.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan

Share this post


Link to post
Share on other sites
If you want *all* the public members of the base class to be protected/private in the derived class you can use protected/private inheritance rather than public inheritance.

- Neophyte

Share this post


Link to post
Share on other sites
The reason why you can call a private virtual method like that is because changing access specifiers shouldn''t change the meaning of the program.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!