Design flaw in C++?

This is a discussion on Design flaw in C++? within the C++ Programming forums, part of the General Programming Boards category; Only then the const version is called Wouldn't that just fail to compile, since the const version hides the non-const ...

  1. #16
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #17
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Quote Originally Posted by IceDane View Post
    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.

  3. #18
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by CornedBee View Post
    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

  4. #19
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #20
    Registered User
    Join Date
    Jun 2007
    Posts
    219
    Quote Originally Posted by @nthony View Post
    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.

  6. #21
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Other than reiterating various known facts and merging them with meaningless ranting, the initial question was "why?" not "what?"

  7. #22
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    Quote Originally Posted by noobcpp View Post
    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...

  8. #23
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Did you put the excessively-whiny-about-everything-because-i-cant-avoid-not-designing-my-classes-poorly flag? I think its a gcc thing.

  9. #24
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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...

  10. #25
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Fair enough. I am sure Stroustrup will send you back a personally autographed punch card from the first IBM mainframe he ever programmed.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Implementing Inheritence into your design
    By bobthebullet990 in forum C++ Programming
    Replies: 6
    Last Post: 08-05-2006, 05:40 PM
  2. Cprog tutorial: Design Patterns
    By maes in forum C++ Programming
    Replies: 7
    Last Post: 10-11-2004, 02:41 AM
  3. linked list of templates (or a design flaw?)
    By Ess in forum C++ Programming
    Replies: 3
    Last Post: 11-30-2002, 08:15 PM
  4. is this a design flaw
    By blight2c in forum C++ Programming
    Replies: 5
    Last Post: 03-20-2002, 12:33 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21