Thread: 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

this begs another question... can you publicly override a virtual function in the derived class that is private in the base class?

Originally Posted by grumpy

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)

Originally Posted by grumpy

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?

Originally Posted by grumpy

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).

Originally Posted by grumpy

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.

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...

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.

Originally Posted by Elkvis

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.

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.

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..

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?

Originally Posted by whiteflags

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

Originally Posted by whiteflags

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.

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?

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.

Originally Posted by Elkvis

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.

Originally Posted by whiteflags

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.

Originally Posted by whiteflags

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.

Originally Posted by grumpy

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.

Originally Posted by grumpy

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.

Originally Posted by grumpy

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).