Inheritance From Abstract Class Question(s)

This is a discussion on Inheritance From Abstract Class Question(s) within the C++ Programming forums, part of the General Programming Boards category; Hey, I just had some Q's about inheritance in C++. A) The view modifier prepended before the class name that ...

  1. #1
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196

    Inheritance From Abstract Class Question(s)

    Hey,

    I just had some Q's about inheritance in C++.

    A) The view modifier prepended before the class name that you're inheriting from, that sets a MINIMUM level of restriction, in that instance of the class, ie. if C inherits from P, and P has all private members, but it's inherited with private restriction, then the members of P are accessible from C as if they were C's private members? But if they were all public, declaring the inheritance as public won't give C access to P's private members.

    B) Even if a function is private, if declared pure virtual (void function), the class is therefore abstract and cannot be instantiated, right? So what would the point of writing a function that's pure virtual without code under a private visbility in a parent class be?? I have some code that I didn't write (but I can't post here ) that has that, and I'm trying to figure out the rationale behind it. There's no way a child could implement that, it's private, right?

    Thanks for your time!!!

    - Greg

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,307
    Quote Originally Posted by Syndacate View Post
    A) The view modifier prepended before the class name that you're inheriting from, that sets a MINIMUM level of restriction, in that instance of the class, ie. if C inherits from P, and P has all private members, but it's inherited with private restriction, then the members of P are accessible from C as if they were C's private members? But if they were all public, declaring the inheritance as public won't give C access to P's private members.
    Incorrect. In fact, exactly the opposite.

    Inheritance (public, protected, private) can not increase accessibility of inherited members. Either the accessibility remains the same or is it reduced.

    A derived class therefore can never have direct access to a private member of a base class.

    Quote Originally Posted by Syndacate View Post
    B) Even if a function is private, if declared pure virtual (void function), the class is therefore abstract and cannot be instantiated, right? So what would the point of writing a function that's pure virtual without code under a private visbility in a parent class be?? I have some code that I didn't write (but I can't post here ) that has that, and I'm trying to figure out the rationale behind it. There's no way a child could implement that, it's private, right?
    A class with a pure virtual function cannot be instantiated. Period. A derived class must override an inherited pure virtual, or the derived class cannot be instantiated either.

    The thing to realise is that declaring a function as pure virtual does not disallow implementing it (i.e. providing a body).

    So
    Code:
    class X
    {
    
        virtual void func() = 0;
    };
    
    void X::func()    // this is perfectly legal
    {
        std::cout << "X::func()\n";
    }
    The purpose in declaring func() as private (so it is a private pure virtual function) is that a derived class is not allowed to call it.

    This prevents things like
    Code:
    class Y : public X
    {
         void func();   // yes, this is allowed, it overrides X::func()
    };
    
    void Y::func()
    {
         X::func();        // not allowed as func() is private to X
    
         std::cout << "Y::func()\n";
    }
    Why would you do this? Because other member functions of class X may need to call X::func(), but we don't want derived classes to call it.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,421
    this begs another question... can you publicly override a virtual function in the derived class that is private in the base class?

  4. #4
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by grumpy View Post
    Incorrect. In fact, exactly the opposite.

    Inheritance (public, protected, private) can not increase accessibility of inherited members. Either the accessibility remains the same or is it reduced.
    Yeaaaa, that's what I meant by the explanation, couldn't decide if it was maximum protection or minimum :-P. In short, you can't DECREASE protection (ie. make it more 'open') by inheriting from it (that's why I determined 'minimum' - but I guess it's not the minimum, it's the minimum only if it's less than what the parent class has, in which case, THAT'S the minimum. Right? (If that made any sense)

    Quote Originally Posted by grumpy View Post
    A derived class therefore can never have direct access to a private member of a base class.
    Right, that's what I thought, that's what protected was for, if I'm understanding it correctly. To have private aspects to the outside world, but allow children access.

    If the children get public access to a parent's protected members, then the members stay protected under the child's visibility, as in nobody accept the child and the child's children can access them, correct?

    Quote Originally Posted by grumpy View Post
    A class with a pure virtual function cannot be instantiated. Period. A derived class must override an inherited pure virtual, or the derived class cannot be instantiated either.
    Right, I should have just taken that at face value instead of trying to think about it - since the compiler knows not how large the class is, it is unable to instantiate an instance of it - ever, at the risk of it being called (this is where I fail to see the usefulness of DLL's).

    Quote Originally Posted by grumpy View Post
    The thing to realise is that declaring a function as pure virtual does not disallow implementing it (i.e. providing a body).

    So
    Code:
    class X
    {
    
        virtual void func() = 0;
    };
    
    void X::func()    // this is perfectly legal
    {
        std::cout << "X::func()\n";
    }
    The purpose in declaring func() as private (so it is a private pure virtual function) is that a derived class is not allowed to call it.

    This prevents things like
    Code:
    class Y : public X
    {
         void func();   // yes, this is allowed, it overrides X::func()
    };
    
    void Y::func()
    {
         X::func();        // not allowed as func() is private to X
    
         std::cout << "Y::func()\n";
    }
    Why would you do this? Because other member functions of class X may need to call X::func(), but we don't want derived classes to call it.
    Well if that's the case, why would func() be pure virtual? I think I'm missing some major concept here.

    I wish I can post the code I have, it'd make it a lot easier, but due to licensing (unofficial, I just don't want it dumping back in my lap) restrictions I can't . This code is pure virtual, private, function prototype, WITHOUT an implementation.

    So the way I take that to say is:
    "An inheriting class must implement this function, it can not be protected or public, it must be private"

    Am I right in that assessment?

    Just seems like overly-restricted coding to me.. Why would you tell a child what it HAS to have at its private levels? That seems like the exact opposite of OOP, the concept of: "You don't have to know what's going on in there, it's referentially transparent, if they choose to implement it with a linked list, or a bunch of kids in a 3rd world nation remembering the numbers manually, you won't know about it" - this seems to violate that principle of sorts...b/c if you have a function that relies on another function (a private function), that's YOUR business, as the parent, shouldn't dictate how the child implements that function....what if the child's implementation of that function is a ternary operator return?? Talk about wasted code..

    So pure virtual functions CAN have code, which makes them similar to abstract classes in Java. This way I can declare functions A and B in public visibility, declaring them virtual in the parent, and implement them, and make functions C and D (also in the parent), also with public visibility, and make them pure virtual.

    Now a class that has inherits from the above will HAVE TO implement C and D. Now something else that calls this inheriting class can call all of the above, A and B are happening in the parent class, and C and D are specific to the implementing class.

    Is that the way I'm understanding pure virtual / abstract / void classes?

    This leads me to another Q about inheriting from a pure virtual..constructors. How the hell do you inherit from it? The sub-object constructor of the inheriting class's constructor has to create an instance of the parent...but how can it do that? The class can't be instantiated.

    I did it in another project I was working on, and the defined sub-object constructor I made in the parent class (so the default c'tor was gone), and somehow it's able to call the pure virtual sub-object c'tor on construction...how??



    Sorry for the 1001 questions, I'm a total idiot when it comes to programming, I haven't been doing it since mid-school like a lot of people I know, and especially with OOP concepts because I'm a practical person, and whenever I ask around, nobody seems to be able to give me ANY form of an example of some OOP concepts, they just say "because that's the way you do OOP"

    If C had namespaces for some function name obfuscation, and templates I'd never leave it. Though unfortunately I have to for a few current projects...OOP is just there b/c it's there, and it fits better with UML and design aspects... I don't actually believe you can get better designs with C++, I simply believe it's a different TYPE of design as you would in C++...though that's just one, rather inexperienced programmer's opinion. Makes me wonder if C++ would have taken off like it did if Smalltalk wasn't around..

    Anywho, thanks for the information, all.

    Quote Originally Posted by Elkvis
    this begs another question... can you publicly override a virtual function in the derived class that is private in the base class?
    As I understand it, no. I'm pretty sure I've even run into that problem, it will give you the error message: "cannot override function <prototype>"

    Also, as I understand C++ inheritance aspects, you cannot expose MORE of a class, you can simply RESTRICT more of it.

    EDIT: Somebody please correct me if I'm wrong, I'd hate to give the guy wrong info...

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    2,421
    I didn't have access to my dev machine before, so I wasn't able to test for myself. I have since written some test code to answer my own question:

    Code:
    class A
    {
      private:
        virtual void foo() = 0;
    };
    
    class B : public A
    {
      public:
        virtual void foo() {  }
    };
    this compiles on GCC 4.5.0, with public or private inheritance.

  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,307
    A pure virtual function means that a derived class is required to override it. The accessibility of that function controls who is allowed to call the base class version. The derived class controls who is allowed to call the derived class version.

    So, yes, a base class can specify a private pure virtual function, and a derived class can publicly override it. The base class is controlling who can call the base class version (if implemented). The derived class is controlling who can call the derived class version. Each class is controlling something that it owns.

    A key concern with OO is controlling who has access to what. Granting more access means it is easier to do useful things, but also makes it easier to do problematic things (eg code can overwrite something that it should not). Hence type of access granted (or revoked) is important: granting too much access is as bad as not granting enough - either can be problematical. The practical challenge, when tackling any problem, is working out the appropriate levels of access.

    It is not a good idea to think in Java terms when considering how C++ works. C++ can do things easily that are difficult in Java (and vice versa).

    In terms of constructors: a derived class effectively contains some representation of the base class. Unlike Java, C++ does not impose a fundamental distinction between interfaces, abstract classes, or other classes. An abstract class can therefore (optionally) have data members in C++. That base class representation has to be initialised. Base class constructors are how that is done. The process of constructing a derived class therefore invokes a constructor of the base class, and then invokes a constructor of the derived class. That allows separation of concerns: a derived class constructor does not have to worry about initialising the base class aspects.
    Last edited by grumpy; 01-21-2011 at 02:42 PM.
    Right 98% of the time, and don't care about the other 3%.

  7. #7
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by Elkvis View Post
    I didn't have access to my dev machine before, so I wasn't able to test for myself. I have since written some test code to answer my own question:

    Code:
    class A
    {
      private:
        virtual void foo() = 0;
    };
    
    class B : public A
    {
      public:
        virtual void foo() {  }
    };
    this compiles on GCC 4.5.0, with public or private inheritance.
    Is it accessible, though? From an outside source? That makes no sense in accordance with this "restrict visibility, bu can't add visibility" approach that many people agree C++ took. Visibility relating to inheritance in C++ is WEIRD. I definitely need to find a site that lays the whole thing out, nice and simple.

    Quote Originally Posted by grumpy
    A pure virtual function means that a derived class is required to override it. The accessibility of that function controls who is allowed to call the base class version. The derived class controls who is allowed to call the derived class version.

    So, yes, a base class can specify a private pure virtual function, and a derived class can publicly override it. The base class is controlling who can call the base class version (if implemented). The derived class is controlling who can call the derived class version. Each class is controlling something that it owns.
    Yes, but does that mean if I have a pointer to the base class, I can call the function, not knowing whether it's private or public in the derived class? I'm assuming if I have a pointer to the base it's aware that the function is private in the base.

    Quote Originally Posted by grumpy
    A key concern with OO is controlling who has access to what. Granting more access means it is easier to do useful things, but also makes it easier to do problematic things (eg code can overwrite something that it should not). Hence type of access granted (or revoked) is important: granting too much access is as bad as not granting enough - either can be problematical. The practical challenge, when tackling any problem, is working out the appropriate levels of access.
    I got the rationale behind privacy...while I don't get what it has to do with...ANYTHING, I understand why it's there. For example, in OO style programming, you should use accessors/mutators style to set/get a private variable within an object - opposed to just making the variable public and accessing it like a struct. I have yet to figure out WHY, C manages it just fine with structs. Everybody just says "that's just the way you do OOP" - which is a BS answer, IMO. I don't get the usefulness of all these BS practices in OOP, and I feel it's offensive to the programmer - what they're basically saying is: "We trust you enough to code this application, but not enough to not ........ IT UP." Weird system..

    Quote Originally Posted by grumpy
    It is not a good idea to think in Java terms when considering how C++ works. C++ can do things easily that are difficult in Java (and vice versa).

    In terms of constructors: a derived class effectively contains some representation of the base class. Unlike Java, C++ does not impose a fundamental distinction between interfaces, abstract classes, or other classes. An abstract class can therefore (optionally) have data members in C++. That base class representation has to be initialised. Base class constructors are how that is done. The process of constructing a derived class therefore invokes a constructor of the base class, and then invokes a constructor of the derived class. That allows separation of concerns: a derived class constructor does not have to worry about initialising the base class aspects.
    So basically there is a base c'tor, and it's called by the sub-object c'tor of the c'tor in the derived class - but it only initializes the memory part (the data members) for the base class, and incorporates them into the derived class?

  8. #8
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,706
    "We trust you enough to code this application, but not enough to not ........ IT UP."
    The concept of privacy has nothing to do with what the programmer could do, but that is a popular misconception. If you provide a function as part of an interface, you'd want other code to use it so that your object is being used in a deterministic fashion, rather than just allowing things to modify data members unnecessarily. If you think about it, C is no different in this regard: A C library is likely to include functions that you are expected to use on data structures. A rather lame observation is that in OOP, now that code is part of a class. So, it's really just a matter of how a particular program gets something done (ignoring a few other concepts introduced by the paradigm). If you're writing an object-oriented program, you're more likely to tackle a task with classes. In procedural (C) code, a task will be tackled with separate functions operating on plain old data. I'd recommend this thread for further reading, actually.

    So basically there is a base c'tor, and it's called by the sub-object c'tor of the c'tor in the derived class - but it only initializes the memory part (the data members) for the base class, and incorporates them into the derived class?
    Yes. The base class constructor is called first thing in the derived class constructor, and then the derived object is initialized on top of that. All constructors initialize objects.
    Last edited by whiteflags; 01-25-2011 at 11:51 AM.

  9. #9
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by whiteflags View Post
    The concept of privacy has nothing to do with what the programmer could do, but that is a popular misconception. If you provide a function as part of an interface, you'd want other code to use it so that your object is being used in a deterministic fashion, rather than just allowing things to modify data members unnecessarily. If you think about it, C is no different in this regard: A C library is likely to include functions that you are expected to use on data structures. A rather lame observation is that in OOP, now that code is part of a class. So, it's really just a matter of how a particular program gets something done (ignoring a few other concepts introduced by the paradigm). If you're writing an object-oriented program, you're more likely to tackle a task with classes. In procedural (C) code, a task will be tackled with separate functions operating on plain old data. I'd recommend this thread for further reading, actually.
    I'll take a look in a few - thx

    Quote Originally Posted by whiteflags View Post
    Yes. The base class constructor is called first thing in the derived class constructor, and then the derived object is initialized on top of that. All constructors initialize objects.
    Yeah, I was j/w b/c the base class was/is abstract, it can't be instantiated. So I take it that's simply what you can/can't do EXTERNALLY, as in C++ under the hood has no problem doing it with what parts it knows what to do with using the sub-object c'tor in the derived class.

  10. #10
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    I don't believe that thread pertains to the same thing I same thing I am asking.

    He is/was simply a guy who doesn't understand when to use an object, when to make a class for something, or how to perform OOP.

    I'm a guy simply wondering why certain OOP practices exist. Objects definitely come in handy, in C sometimes I wish I could call a function on a struct, but then I typically just make a function and pass it a pointer to the struct - problem solved. Though some of the practices that OOP people enforce just seem crazy to me. One of the most prominent ones is the accessor/mutator for member variable method - I just don't get the rationale, I see no difference between a function that sets a variable to the argument passed in, and directly setting the variable to something else - only difference I see is a waste of commands to set up the stack for the accessor/mutator..

    Another thing I don't get is the visibility stuff. I get how it works, when it should be used, etc. and people say "it's for people who will use your code, maintenance, etc." - but what's that really saying, that they're not smart enough to not screw it up, either?

  11. #11
    Registered User
    Join Date
    Oct 2006
    Posts
    2,421
    Quote Originally Posted by Syndacate View Post
    I see no difference between a function that sets a variable to the argument passed in, and directly setting the variable to something else - only difference I see is a waste of commands to set up the stack for the accessor/mutator.
    it's not uncommon to have the getter/setter perform other operations beside just setting/getting the value. this concept is called encapsulation. the idea is that you don't know ANYTHING about the internal structure of the class, but only its interface. if the calling code knew everything about the internal structure, then there's not even any reason for the class in the first place. the caller might as well just manipulate a struct or even a set of local variables. classes give you the ability to implement an interface and change the code behind the scenes, without the caller knowing about it. the caller only needs to know that a PROPERTY is being changed, regardless of how that property is stored, whether it's a simple variable, or a computed value or whatever you like.

    a good example would be the accounting software I work on at my job. an account does not store a local variable called "balance" but an account has an accessor called "GetBalance." the accessor adds up all the transactions that happened to the account and returns the result. at no time is it getting or setting the value of a member variable.
    Last edited by Elkvis; 01-25-2011 at 04:29 PM.

  12. #12
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,706
    Quote Originally Posted by Syndacate
    Another thing I don't get is the visibility stuff. I get how it works, when it should be used, etc. and people say "it's for people who will use your code, maintenance, etc." - but what's that really saying, that they're not smart enough to not screw it up, either?
    Well people can screw up anyway, so that cannot be the point. I barely trust code that I wrote myself that to my knowledge only I am using.

    It sounds like you understand a lot of technical details, but don't see the benefits. Imagine how stupid the STL would be, if it were composed of glorified structs. Have you looked at that code? Wouldn't using it, with an eye towards the implementation details, be much more painful than it actually is? You can't really appreciate things like visibility, accessors and mutators when you are implementing a class. You've hit bedrock, and it is time to do dirty work. Much ado is made in C++ about programming at a "higher level" and when you use a working class (no matter if you wrote it yourself at one point) to accomplish part of the job, that's when you're finally doing it.

  13. #13
    Registered User
    Join Date
    Jun 2005
    Posts
    6,307
    Quote Originally Posted by Syndacate View Post
    Yes, but does that mean if I have a pointer to the base class, I can call the function, not knowing whether it's private or public in the derived class? I'm assuming if I have a pointer to the base it's aware that the function is private in the base.
    Given a pointer to base, a member function of base or a friend of base can execute a call of the member function (some_base->member_function()). That is true whether member_function() is public, protected, or private.

    If member_function is private to base, and derived overrides it, then - by the act of overriding - the derived class grants permission for any code executing some_base->member_function() to call derived::member_function.

    In overriding any virtual function, the derived class essentially makes a statement that it will comply with expectations of the base class (eg accepted preconditions, post-conditions, etc)

    Quote Originally Posted by Syndacate View Post
    I got the rationale behind privacy...while I don't get what it has to do with...ANYTHING, I understand why it's there. For example, in OO style programming, you should use accessors/mutators style to set/get a private variable within an object - opposed to just making the variable public and accessing it like a struct. I have yet to figure out WHY, C manages it just fine with structs. Everybody just says "that's just the way you do OOP" - which is a BS answer, IMO. I don't get the usefulness of all these BS practices in OOP, and I feel it's offensive to the programmer - what they're basically saying is: "We trust you enough to code this application, but not enough to not ........ IT UP." Weird system..
    You are understanding there is a mechanism related to privacy, but not its rationale.

    Firstly, in the real world, programmers make mistakes. Trust in a programmer does not mean assuming they will not make mistakes.

    Second, when writing code that other programmers will use, you have to assume those programmers will make mistakes. It is also necessary to assume you will make mistakes. It doesn't matter how skilled and disciplined you or other programmers are: you are human, you make mistakes.

    Third, if someone makes a mistake, it is necessary to manage the consequences (eg damages) caused by that mistake. You can't assume you know what the mistakes are either - if you could, you could eliminate the mistakes.

    Access control is just one means of managing the implications of mistakes. If some function does not have access to do something, then that limits opportunities to make mistakes while doing that something. For example, it allows early detection of mistakes - for example, a mistake is caught with a compilation error rather than a bug report from a disgruntled end user.

    Granting universal access - as in C - gives flexibility. The trade-off is that more mistakes can be made, and they are more widespread. Even a skilled and disciplined programmer will make mistakes, and his/her job is made easier (and more productive, and satisfying) by catching those mistakes early. The trends in software engineering are also towards allowing unskilled and undisciplined programmers to do more critical work. With that trend, it is definitely necessary to put more safety nets in place. Access control is one of those safety nets.

    Quote Originally Posted by Syndacate View Post
    So basically there is a base c'tor, and it's called by the sub-object c'tor of the c'tor in the derived class - but it only initializes the memory part (the data members) for the base class, and incorporates them into the derived class?
    Approximately.
    Last edited by grumpy; 01-25-2011 at 05:39 PM.
    Right 98% of the time, and don't care about the other 3%.

  14. #14
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by Elkvis View Post
    it's not uncommon to have the getter/setter perform other operations beside just setting/getting the value. this concept is called encapsulation. the idea is that you don't know ANYTHING about the internal structure of the class, but only its interface. if the calling code knew everything about the internal structure, then there's not even any reason for the class in the first place. the caller might as well just manipulate a struct or even a set of local variables. classes give you the ability to implement an interface and change the code behind the scenes, without the caller knowing about it. the caller only needs to know that a PROPERTY is being changed, regardless of how that property is stored, whether it's a simple variable, or a computed value or whatever you like.

    a good example would be the accounting software I work on at my job. an account does not store a local variable called "balance" but an account has an accessor called "GetBalance." the accessor adds up all the transactions that happened to the account and returns the result. at no time is it getting or setting the value of a member variable.
    I believe I came off the wrong way. I was taught in Java, so I understand the concepts behind encapsulation, and OOP in general...I just don't understand the rationale behind some (most) of it.

    I understand that a mutator might do something more, like increment a static private member variable or something...but what if it doesn't...why not just change the variable directly? I see all these OOP gurus flipping ........ over that but I really don't see the big deal. If you KNOW (ie. you have the source code for the implementation) that it's simply changing the variable, I see no reason for the extra stack overhead...you can eliminated some of that by inlining an accessor or mutator that's that simple, but people generally don't.

    Quote Originally Posted by whiteflags View Post
    Well people can screw up anyway, so that cannot be the point. I barely trust code that I wrote myself that to my knowledge only I am using.
    Which is exactly my point. What it basically says is "Whoever wrote this interface did it right, you probably won't, though." People can screw it up anyway, and IMO it's better if somebody finds it, than just assuming everything is peachy on the other side.

    Quote Originally Posted by whiteflags View Post
    It sounds like you understand a lot of technical details, but don't see the benefits. Imagine how stupid the STL would be, if it were composed of glorified structs. Have you looked at that code? Wouldn't using it, with an eye towards the implementation details, be much more painful than it actually is? You can't really appreciate things like visibility, accessors and mutators when you are implementing a class. You've hit bedrock, and it is time to do dirty work. Much ado is made in C++ about programming at a "higher level" and when you use a working class (no matter if you wrote it yourself at one point) to accomplish part of the job, that's when you're finally doing it.
    You're right, and I've dug through a proprietary STL implementation one too many times at my old job. It is a convoluted mess in there. I would probably NEVER want to call those functions, true...but I'd still like the option to..?

    I feel like it's taking away the rights/flexibility that the programmer has. I'm glad that it's hidden, but I'd like the choice to keep it hidden.

    Quote Originally Posted by grumpy View Post
    Given a pointer to base, a member function of base or a friend of base can execute a call of the member function (some_base->member_function()). That is true whether member_function() is public, protected, or private.

    If member_function is private to base, and derived overrides it, then - by the act of overriding - the derived class grants permission for any code executing some_base->member_function() to call derived::member_function.

    In overriding any virtual function, the derived class essentially makes a statement that it will comply with expectations of the base class (eg accepted preconditions, post-conditions, etc)
    Ah, that makes sense.

    Quote Originally Posted by grumpy View Post
    You are understanding there is a mechanism related to privacy, but not its rationale.

    Firstly, in the real world, programmers make mistakes. Trust in a programmer does not mean assuming they will not make mistakes.

    Second, when writing code that other programmers will use, you have to assume those programmers will make mistakes. It is also necessary to assume you will make mistakes. It doesn't matter how skilled and disciplined you or other programmers are: you are human, you make mistakes.

    Third, if someone makes a mistake, it is necessary to manage the consequences (eg damages) caused by that mistake. You can't assume you know what the mistakes are either - if you could, you could eliminate the mistakes.

    Access control is just one means of managing the implications of mistakes. If some function does not have access to do something, then that limits opportunities to make mistakes while doing that something. For example, it allows early detection of mistakes - for example, a mistake is caught with a compilation error rather than a bug report from a disgruntled end user.
    True, but on the flipside, it 'protects' at the cost of flexibility. It's the same problem with 'const' - I've seen too many times where somebody made something const because at the time, it only needed to be accessed, but later, as the code evolved some, it (the variable assigned to whatever const was returned) needed to be modified..people can't foresee the future.

    Sometimes you DON'T want to call a public member function which may do something you don't want it to (ie. increment a counter), sometimes you just may want that private function, to calculate a pointer location or something. So you end up with code duplication.

    Quote Originally Posted by grumpy View Post
    Granting universal access - as in C - gives flexibility. The trade-off is that more mistakes can be made, and they are more widespread. Even a skilled and disciplined programmer will make mistakes, and his/her job is made easier (and more productive, and satisfying) by catching those mistakes early. The trends in software engineering are also towards allowing unskilled and undisciplined programmers to do more critical work. With that trend, it is definitely necessary to put more safety nets in place. Access control is one of those safety nets.



    Approximately.
    Yeah, I think that's pretty much it. They trade flexibility for 'safety.' Which is stupid, IMO. I never claimed I was perfect, far from it, especially in terms of coding...but if I make a mistake, I'd like it to come back and bite me in the ass. Why? because I'm not programming in Java for it to hold my hand every step of the way. If I wanted that kind of security I'd program in Java.

    I guess the way I feel is that C++ is undecided.. Take C, gives the user complete control, [almost] exactly what you tell it to do, it does. Java on the other hand, holds your hand like a babysitter, to keep you from making every mistake possible for it to see you making it.

    C++ sits in the middle, it's supposed to be 'close to the hardware' and 'efficient' - like C is, but it wants to hold your hand as much as it can. One language can't do everything. Now, granted, C++ is a good attempt at the best of both worlds, I'd still say some of the idiosyncrasies of OO practices are that it can hinder both performance, as well as flexibility (ie. jumping through proverbial hoops).

  15. #15
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,743
    Quote Originally Posted by Syndacate
    I feel like it's taking away the rights/flexibility that the programmer has. I'm glad that it's hidden, but I'd like the choice to keep it hidden.
    The author/maintainer would like that choice too. If you make use of the implementation details and then the details change without warning, are you going to complain? You might say no now, but when you really could use some new feature or critical bug fix that comes at the cost of breaking your current working code that depends on an implementation detail that is now non-existent, you might start complaining pretty loudly even though it is entirely your fault.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

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

Similar Threads

  1. Inheritance and pure virtual functions
    By Swerve in forum C++ Programming
    Replies: 3
    Last Post: 03-12-2010, 12:30 PM
  2. Whats the best way to control a global class?
    By parad0x13 in forum C++ Programming
    Replies: 3
    Last Post: 11-12-2009, 04:17 PM
  3. Inheritance, istream, class datamember
    By guda in forum C++ Programming
    Replies: 4
    Last Post: 09-30-2004, 12:25 PM
  4. Abstract class problem
    By VanJay011379 in forum C++ Programming
    Replies: 9
    Last Post: 07-31-2002, 01:30 PM
  5. Problems w.r.t Virtual Base Class (inheritance)
    By pankajdynamic in forum C++ Programming
    Replies: 1
    Last Post: 04-15-2002, 10:28 AM

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