Design flaw in C++?

Code:

---

class EventHandler
{
  public: virtual void handleEvent( ) { cout << "default handler" }
}

class MyEventHandler : public EventHandler
{
  private: void handleEvent( ) { cout << "my handler" }
}

void handleEvents( EventHandler *eh )
{
  eh->handleEvent( );
}

int main()
{
  handleEvents( MyEventHandler() );
}

---

To my surprise the private member function is called directly rom a public context!! What is the moral of the story here? That the private keyword is disrespected when you declare a member function sharing the same name as a public one in a base class? I guess I could go with that, otherwise there'd be ambiguity between private Foo::x and public BaseFoo::x within Foo itself. HOWEVER, should the compiler not at least warn me that it's going to drop my privates (so to speak) in this situation!? Seems a tad shady...

The compiler doesn't know (at least in the general case) that MyEventHandler even exists, so it can't warn you that you are calling a function that is private in the derived class.

The point of the dynamic polymorphism here is that the dynamic type of eh is determined at run time, not compile time. That means that at compile time, as long as handleEvent is callable from the EventHandler interface then the code is valid.

Hmm, I see now. I think they could have done a better job with the semantics of the private keyword in this case, but I guess specs are specs for a reason...

Code:

---

11.6 Access to virtual functions [class.access.virt]
1 The access rules (clause 11) for a virtual function are determined by its declaration and are not affected by the rules for
a function that later overrides it. [ Example:
class B {
public :
virtual int f();
};
class D : public B {
private :
int f();
};
void f()
{
Draft
217 Member access control 11.7 Multiple access
D d;
B* pb = & d;
D* pd = & d;
pb ->f (); / / OK: B::f() is public,
/ / D::f() is invoked
pd ->f (); / / error: D::f() is private
}
—end example ]

---

Quote:

---

I think they could have done a better job with the semantics of the private keyword in this case

---

You could have done a better job with keeping to the Liskov substitution principle. Public inheritance means "is-a", thus an attempt to make private an override of a public member function is a design flaw in your own code.

The real question is, why doesn't the compiler complain the moment you override a function with one that has lesser access?

I know I saw a rationale for that once, but I can't remember where or what it was.

I think its more of a design flaw on your behalf than on the language's behalf. You could use this sort of thing for encapsulation, though you would be utilizing it in the exact reverse of how you just did things here. Though anyone who has access to the original base object, theoretically always can gain access to any subsequent derivation of that class. So I don't think there is much logical reason to try using it in a positive way. At least nothing overly contrived that I can work up now (hense my lack of an example).

Quote:

---

Originally Posted by CornedBee

The real question is, why doesn't the compiler complain the moment you override a function with one that has lesser access?

I know I saw a rationale for that once, but I can't remember where or what it was.

---

I was thinking exactly the same. Aside from the contrived example I gave (which may or may not be paradigm-correct), I can see a scenario occuring in which someone derives from some public API base class, forgets about some obscure inherited virtual they never intend to use and accidentally declares a private function of the same name. In which case it would be beneficial to issue a warning to the effect of

Quote:

---

warning: private member function foo overloads public virtual function bar of class Fred - private access modifier will be ignored

---

I thought this type of override does throw a warning on all the major compilers.

Quote:

---

Originally Posted by master5001

I thought this type of override does throw a warning on all the major compilers.

---

g++ (MinGW's g++, anyway), using -Wall and -Wextra, says this:

Code:

---

---

For shame, g++! Even with pedantic flags? Bleh this machine doesn't have any compilers on it.

To be fair, Visual Studio 2008 C++ says this:

Code:

---

---

Those are all the compilers I can get to.

I don't think you can get any more common-place than VC++ and gcc. I mean I could break out a Borland one but I really couldn't care less what faults that one finds in anything.

Private, public and protected and any mechanismsin C++ that are made in order to deny access to memory that was not intended to be accessed by the accessor(Lawl), are purely language semantics. If you were to compile an executable that initializes a class with a public variable and private variable, initializes both and prints the public one, and then run it through a debugger and swap out the address of the public variable that's being accessed in your print function, with the private variable's address, nothing would happen.

The memory isn't protected. AFAIK, there is no such mechanism in (at least) windows, except to change Read/Write/Copy privileges and so on. AFAIK, you cannot prohibit a process to access its own memory due to the current context of the running code.

That's understood (in fact, the same could be done for "const"ness).
Instead, we're discussing what happens at compile time, when overloading a public virtual with a private changes the normal semantics of the "private" keyword.
Actually, I was just going to draw analogy to "const", but looks like this suffers from similar problems:

Code:

---

class EventHandler
{
  public: virtual void handleEvent( ) { d++; }
  int d;
};

class MyEventHandler : public EventHandler
{
 // woops! there goes the "const"ness
 // so much for empty promises
  private: void handleEvent( ) const { (void)e; }
  int e;
};

void handleEvents( EventHandler *eh )
{
  eh->handleEvent( );
}

int main()
{
  MyEventHandler meh;
  handleEvents( &meh );
}

---

Surprisingly, "const"ness is violated here and still no warning is generated! These are the kinds of things I'd expect a compiler to flag (all the necessary information is present at compile time). The fact that private and const semantics can change so discreetly does seem a bit of a design flaw...

Quote:

---

Originally Posted by @nthony

That's understood (in fact, the same could be done for "const"ness).
Instead, we're discussing what happens at compile time, when overloading a public virtual with a private changes the normal semantics of the "private" keyword.
Actually, I was just going to draw analogy to "const", but looks like this suffers from similar problems:

Code:

---

class EventHandler
{
  public: virtual void handleEvent( ) { d++; }
  int d;
};

class MyEventHandler : public EventHandler
{
 // woops! there goes the "const"ness
 // so much for empty promises
  private: void handleEvent( ) const { (void)e; }
  int e;
};

void handleEvents( EventHandler *eh )
{
  eh->handleEvent( );
}

int main()
{
  MyEventHandler meh;
  handleEvents( &meh );
}

---

Surprisingly, "const"ness is violated here and still no warning is generated! These are the kinds of things I'd expect a compiler to flag (all the necessary information is present at compile time). The fact that private and const semantics can change so discreetly does seem a bit of a design flaw...

---

Nothing surprising here. The const version does not override the one in the baseclass so when you have a EventHandler * the one in the baseclass gets called. If you want the const version you'll have to cast it.

Code:

---

((MyEventHandler *)handle)->handleEvent();

---

Only then the const version is called

Quote:

---

Only then the const version is called

---

Wouldn't that just fail to compile, since the const version hides the non-const version, and the const version can't be called with the non-const pointer?

Quote:

---

Originally Posted by IceDane

The memory isn't protected. AFAIK, there is no such mechanism in (at least) windows, except to change Read/Write/Copy privileges and so on. AFAIK, you cannot prohibit a process to access its own memory due to the current context of the running code.

---

Which is why casting can break encapsulation as well as access rights. C++ is subject to C shenanigans.

Quote:

---

Originally Posted by CornedBee

Wouldn't that just fail to compile, since the const version hides the non-const version, and the const version can't be called with the non-const pointer?

---

The cast takes care of the not compiling part. Of course its VERY crappy code when you do that, it was just an example. If the memory of the object actually resides in read-only memory and the non const version changes members you have yourself a nice crashing program ;)

Quote:

---

The cast takes care of the not compiling part.

---

Not really. The cast casts to a non-const type, and you try to call a const function on it. It should just fail to compile, and if it doesn't, you've got a really weird compiler.

Quote:

---

Originally Posted by @nthony

That's understood (in fact, the same could be done for "const"ness).
Instead, we're discussing what happens at compile time, when overloading a public virtual with a private changes the normal semantics of the "private" keyword.
Actually, I was just going to draw analogy to "const", but looks like this suffers from similar problems:

Code:

---

class EventHandler
{
  public: virtual void handleEvent( ) { d++; }
  int d;
};

class MyEventHandler : public EventHandler
{
 // woops! there goes the "const"ness
 // so much for empty promises
  private: void handleEvent( ) const { (void)e; }
  int e;
};

void handleEvents( EventHandler *eh )
{
  eh->handleEvent( );
}

int main()
{
  MyEventHandler meh;
  handleEvents( &meh );
}

---

Surprisingly, "const"ness is violated here and still no warning is generated! These are the kinds of things I'd expect a compiler to flag (all the necessary information is present at compile time). The fact that private and const semantics can change so discreetly does seem a bit of a design flaw...

---

1. according to your design handleEvents( EventHandler *eh ) seems to take a polymorphic argument and you will invoke the handleEvent() method on that EventHandler* or EventHandler* Derived Object. So making handleEvent private in a derived Class vreaks your own design.

2. when you are casting (void)e you are not changing type of MyEventHandler::e to void rather you are either returning a copy of e which holds the same data of e but type void (which happens here), or returning the value of e in void format.

Other than reiterating various known facts and merging them with meaningless ranting, the initial question was "why?" not "what?"

Quote:

---

Originally Posted by noobcpp

1. according to your design handleEvents( EventHandler *eh ) seems to take a polymorphic argument and you will invoke the handleEvent() method on that EventHandler* or EventHandler* Derived Object. So making handleEvent private in a derived Class vreaks your own design.

---

And unintentionally breaking your own design calls for at least a warning, if not compile time error, wouldn't you agree? Yet the compiler remains silent on this front...

Did you put the excessively-whiny-about-everything-because-i-cant-avoid-not-designing-my-classes-poorly flag? I think its a gcc thing.

I always -Wall myself ;)
At this point I guess, although the standard is a bit flaky in this regard, it's not a flaw in the language so much as in compiler design. Just another thing to add to the mailing list...

Fair enough. I am sure Stroustrup will send you back a personally autographed punch card from the first IBM mainframe he ever programmed.