Design flaw in C++?

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.