Stack/Queue Question

Hello,
first of all if i tried to create a personal stack but compiler reports me these errors:

MyStack.cpp:8: error: template argument required for ‘class StackMio’
MyStack.cpp:8: error: expected template-name before ‘<’ token

The code is:

Code:

---

#ifndef STACKMIO_H
#define STACKMIO_H

#include<list>

template <class T>
class StackMio : private list <T>
{
        public:
                void push(const T& value)
                {
                        push_front(value);
                }
                void pop(const T& value)
                {
                        pop_front(value);
                }
                void print()
                {
                        for(list<T>::iterator it=this->begin();it!=this->end();it++)
                                cout<<*it;
                }
};
#endif

---

Where are the errors? It's the first time i create a template so.. :)

Second question: Can I use iterators like in the "Print" function? I read that the iterators can't be used with queue, stacks etc...So how I could "slide" my Stack/Queue? Thanks

Quote:

---

MyStack.cpp:8:

---

You aren't showing how you are using the template (and that is what the error is about).

Also ...

1. You need to qualifier 'list' with 'std::' (edit: and for the cout)

2. On the for loop, you need a 'typename'

see below:

Code:

---

#ifndef STACKMIO_H
#define STACKMIO_H

#include<list>

template <class T>
class StackMio : private std::list<T>
{
        public:
                void push(const T& value)
                {
                        push_front(value);
                }
                void pop(const T& value)
                {
                        pop_front(value);
                }
                void print()
                {
                        for(typename std::list<T>::iterator it=this->begin();it!=this->end();it++)
                                std::cout<<*it;
                }
};
#endif

---

3. std::stack already exists

OK perfect i forget "using namespace std" and iostream... I know that stack exist, but i'm preparing for an exam and i want to know how i can create my own stack/queue etc...So in a main i can't use for example StackMio<int>::iterator etc because it doesn't exist?

I suggest that you use composition instead of private inheritance. It'll probably be easier for you to think about.

Quote:

---

Originally Posted by Falko-tux

OK perfect i forget "using namespace std" and iostream... I know that stack exist, but i'm preparing for an exam and i want to know how i can create my own stack/queue etc...So in a main i can't use for example StackMio<int>::iterator etc because it doesn't exist?

---

Correct. But you can typedef them. And you should prefer composition over of private inheritance because a stack isn´t a list.

Code:

---

template<typename T>
class StackMio
{
public:
  typedef typename std::list<T>::const_iterator const_iterator;


  const_iterator begin() const
  {
      return Container_.begin();
  }

  const_iterator end() const
  {
      return Container_.end();
  }

  ...

  std::list<T> Container_;
};

---

Quote:

---

Originally Posted by Falko-tux

OK perfect i forget "using namespace std"

---

You shouldn't put a using statement in a header file. Just fully-qualify everything.

Thanks to everybody :)

Quote:

---

Originally Posted by GNiewerth

And you should prefer composition over of private inheritance because a stack isn&#180;t a list.

---

Private inheritance does not imply that a stack is a list.

Scott Meyers and many others consider private inheritance as
"is implemented in terms of" (item 42 in Effective C++ Second Edition).

There is some disagreement on this board ...

http://www.codeguru.com/forum/showthread.php?t=412309

Quote:

---

Originally Posted by laserlight

Private inheritance does not imply that a stack is a list.

---

Not to the outside world, but the derived class can assign an instance of itself to a variable/pointer/reference of/to the type it privately inherits, so in certain context a stack is not a list, while in another it is. Quite a messy situation.

Quote:

---

Originally Posted by TheGreatCthulhu

Not to the outside world, but the derived class can assign an instance of itself to a variable/pointer/reference of/to the type it privately inherits, so in certain context a stack is not a list, while in another it is. Quite a messy situation.

---

It's just a play with words. The mess goes away as soon as you stop using inheritance and is-a interchangibly. The stack is-a list in "the inside world" because you say so, not because you use private inheritance.

Never assign responsibilities to C++ it has never assumed. C++ doesn't define modeling relationships, you do. C++ only supplies language constructs to facilitate your modeling.

Quote:

---

Originally Posted by nuzzle

It's just a play with words. The mess goes away as soon as you stop using inheritance and is-a interchangibly. The stack is-a list in "the inside world" because you say so, not because you use private inheritance.

Never assign responsibilities to C++ it has never assumed. C++ doesn't define modeling relationships, you do. C++ only supplies language constructs to facilitate your modeling.

---

You have a point, but that is not entirely true. You can't just pick any language construct and map it to an arbitrary relationship, as defined by your modeling paradigm. Why? Because logical relationships require certain conditions to be true, make certain assumptions about the general mechanisms that support the semantics. Language constructs impose some of these constraints or capabilities, so at some level they have an impact on what kind of logical relationships they can represent. But, from there, you can have even more specific interpretations of the relationship, that have nothing to do with the language itself.

My point was, within the scope of the class, you can write

Base *pBase = new PrivatelyDerived();

Within the scope of the class, it's almost as if the keyword private wasn't even used. Within, you can do the same things you can do with public inheritance.
Given all that, I think you can safely say that as far as PrivatelyDerived is concerned, PrivatelyDerived is-a Base (or can be considered as such). Of course, you, as the class' designer, can choose to ignore this fact, and than that relationship will have different semantics, but then you better (1) document that with big flashy letters, and (2) better have a d4mn good reason to use private inheritance.
Because private inheritance, no matter how you interpret it, introduces the same problems as public inheritance, along the lines of the semantic fragile base class problem you spoke of yourself in another thread. (Of course, there is a way to introduce the same set of problems using delegation, but only if you try hard :D.)
For most people, it is hard to see what this class of problems actually is, because they are so subtle an stem from all the convoluted and often not-obvious interaction between a class and a superclass. I mean, if you're unlucky, and if some bad design is involved you can even break the base class just by deriving from it (that would be some sort of "semantic fragile subclass problem"). And when I say break, I don't mean it-wont-compile break; I mean it-compiles-but-it-doesn't-work kind of break.
These problems are all related to the fact that, sooner or later, the code will change. If it's done by someone else, or even by the same developer, but after a relatively long (read: long enough) pause, then if the semantics are not well documented, or even if the documentation isn't studied properly, chances are that the the developer will try to reconstruct the logical model from the code, thus being deceived by the language constructs themselves (but, the language is not to blame).

Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer. -- Steve McConnell, software engineer and author, from Code Complete

My point is, when you see

class PrivatelyDerived : private Base

it does tell you something. You just can't be sure what is it exactly that it tries to say, at leas not just based on that.

Quote:

---

Originally Posted by TheGreatCthulhu

Given all that, I think you can safely say that as far as PrivatelyDerived is concerned, PrivatelyDerived is-a Base (or can be considered as such). Of course, you, as the class' designer, can choose to ignore this fact, and than that relationship will have different semantics, but then you better (1) document that with big flashy letters, and (2) better have a d4mn good reason to use private inheritance.

---

Again, this becomes a problem only becuse you define inheritance to always constitute a modeling relationship. It's a definition you impose on C++. Then you claim that because you can tweak inheritance into breaking the modeling relationship there's something wrong with inheritance. But this doesn't follow because inheritance is a language construct defined by the C++ standard and not whatever people want it to be or say it is.

Even so, if you look at this

Base *pBase = new PrivatelyDerived();

for what it is namely an implementation detail your perceived problem goes away. This possible usage doesn't influence your design, it's hidden implementation.

Should you do it? Well that's left to your good judgement (as often in C++) but the fact that you can do it is not an argument against private inheritance. C++ allows you to do pretty much what you like in private and that's good.

I totally understand what are you saying and the separation you're trying to make, and I respect your view. I just don't agree all the way - speaking of programing in general (not just C++), i think it's even counterproductive.
I didn't chose that quote at random: in my mind, an ideal language has a syntax that makes it crystal clear what the intentions of the coder were, and a language where the language features themselves are self-documenting. Of course, in real life, that's probably not possible, except perhaps in some ugly, cumbersome form. But I think a language can find the right balance.
C++ programers often consider C#'s restrictions as some sort of hand-holding, even an insult to the programmer, but they are completely missing the point. And the point is: unless the more complicated, more error-prone way has some huuuuuuuuge benefit, KISS - prevention is better than cure!
It's like saying a safety gate on a dangerous staircase is an insult to Man's intellect. It's just a (sub)set of principles/good-practices embodied into a language, and the price to pay for it is negligible.
I mean, the best designed code often minimizes the possibility of it being misused by clients (accidentally or on purpose) - why shouldn't a programing language strive to do the same?
So that we could concentrate on what really matters instead?

And it's not like these C++ features came first, and then someone said: hey, let's use all this cool stuff and create a modeling paradigm out of it. They were introduced specifically to support OO. Along with a hybrid feature or two. So I argue that language constructs do carry meaning, do carry certain implications about the logical model, at least to some extent.

Quote:

---

Originally Posted by nuzzle

Then you claim that because you can tweak inheritance into breaking the modeling relationship there's something wrong with inheritance. But this doesn't follow because inheritance is a language construct defined by the C++ standard and not whatever people want it to be or say it is.

Even so, if you look at this

Base *pBase = new PrivatelyDerived();

for what it is namely an implementation detail your perceived problem goes away. This possible usage doesn't influence your design, it's hidden implementation.

---

About the design: It shouldn't, but it could.
However, it is an implementation detail of the class, not of the language. The class is not the issue here. In fact, if you consider the syntax as some sort of a public interface of the language itself - then your argument does not hold.
BTW, my intention was not to "tweak inheritance" in order to break the proposed relationship, quite the opposite - I was trying to prove that that the code implies that we're, in fact, dealing with something akin to an is-a relationship, at least in part, at least in the scope of the class. But a one that pretends that it is something else. You're gonna say: only because I'm interpreting it as such. But I'm claiming that language constructs are not completely devoid of meaning - they can't be, it comes from the mechanisms they are backed with.

Don't get me wrong: I'm not saying C++ is bad or something. I'm just saying that I don't see significant added value in features like protected and private inheritance to warrant their inclusion in the language. I believe C++ programmers could live without them just fine.

But, we're polluting the thread, this is way off-topic. And again, I respect your position, and I'm not claiming I'm right no matter what.

Well, there are cases where private inheritance is mandatory, compared to composition. Keeping in the mindset that private inheritance means "is implemented in terms of":

What if the object you are "implementing in terms of" can be customized by overiding a private virtual function?

What if you want your object to be "implemented in terms of" two different classes, both of which virtually derive from the same base class (the dreaded diamond)?

Now, we could argue that any application that does this might best be purged in fire along with all the hardware it has ever touched, but still. Private inheritance can give you more functionality than can be obtained through composition alone.

Composition is probably easier and safer, but just like the pointer vs reference idiom "References when you can, pointers when you must".

Quote:

---

Originally Posted by TheGreatCthulhu

Don't get me wrong: I'm not saying C++ is bad or something. I'm just saying that I don't see significant added value in features like protected and private inheritance to warrant their inclusion in the language. I believe C++ programmers could live without them just fine.

---

Firstly I wanted to point out that you're using a known C++ critisizing pattern.

It goes like this. You're imposing a new meaning (that's not defined by the C++ standard) on a certain construct. Then when C++ doesn't live up to your expectations you declare the construct useless.

My response to this is - lets take C++ at face value. Lets not make it into something it isn't and then blame it for it!

Secondly, the specific case of private inheritance. You're calling on OO here but the whole idea of OO is to separate design from implementation.

And C++ does it nicely. When you're using private inheritance you're in the realms of implementation where C++ grants you the right to do whatever you like including shooting yourself in the foot.

It's as it should be. In C++ the programmer is king. To put it bluntly, without private inheritance C++ would be reduced to just another Java where the programmer is slave. Who wants that? I've just left Java and I don't want it back!

That's why I think you're wrong. But I don't hate you :).

Quote:

---

Originally Posted by monarch_dodra

Well, there are cases where private inheritance is mandatory, compared to composition. Keeping in the mindset that private inheritance means "is implemented in terms of":

What if the object you are "implementing in terms of" can be customized by overiding a private virtual function?

What if you want your object to be "implemented in terms of" two different classes, both of which virtually derive from the same base class (the dreaded diamond)?

Now, we could argue that any application that does this might best be purged in fire along with all the hardware it has ever touched, but still. Private inheritance can give you more functionality than can be obtained through composition alone.

Composition is probably easier and safer, but just like the pointer vs reference idiom "References when you can, pointers when you must".

---

OK, I wouldn't go as far to "purge it all in fire" :D
The way I see it: the mechanics behind the language construct define the outlines a potential modeling relationship, and then the programmer can skillfully mend that to suit one design or another, provided that it's reasonable to use that particular language construct in that situation. So, private inheritance is either expressed primarily as a twisted form of is-a, or (preferably) primarily as an "implemented in terms of" relationship.

I've been very careful with words here, also taking into consideration things pointed out by nuzzle, and I believe this interpretation is pretty sound.

I've read your post and I've been over what are called valid reasons to use it, as pointed out here - as best as I can assess, my reference has enough credibility, but please point out if anything is off.
So, on one hand it gives you power, on the other, it carries hidden problems, which in turn means that to use it properly within a fairly complex, competitive, change-aware, long term project, a deep understanding of the topic is required, although it doesn't always seem that way. That is, IMO, not the best language design - but, it's easy for us to look back now and say that something could have been done differently.

• The reasons mentioned there are:
  
  • 
    [ << "implemented in terms of" >> ]
  • We need access to a protected member.
  • We need to override a virtual function.
  • We need to construct the used object before, or destroy it after, another base subobject.
  • We need to share a common virtual base class, or override the construction of a virtual base class.
    [<< is-a >> ]
  • We need "controlled polymorphism" LSP IS-A, but in certain code only.
    [<< extras >> ]
  • [I'd add a mixin-based approach to all that...]
  • [And the "diamond" inheritance problem...]

These are all strongly indicative of bad design, on both base class side and derived class side. Furthermore, these show how, no matter how you view the relationship, the same coupling that causes fragile baseclass problem and the like exists here.
In other languages, the resulting design would probably be somewhat more complicated, and although it would seem as extra work at first, it would end up being more soundly structured, and more stable yet flexible.
So, IMO, justification would have to be something more than just this. Like, if there's a significant performance benefit in a performance critical application. Or if the legacy/3rd-party code is nearly impossible to work with in any other way.

Quote:

---

Originally Posted by nuzzle

Firstly I wanted to point out that you're using a known C++ critisizing pattern.

It goes like this. You're imposing a new meaning (that's not defined by the C++ standard) on a certain construct. Then when C++ doesn't live up to your expectations you declare the construct useless.

---

Well, I don't think the criticism is entirely unjustified. Otherwise, recommendations to generally avoid protected and private inheritance wouldn't exist, would they? But useless? I didn't say that. I'm just saying that there's probably a better way to do things.

Quote:

---

Originally Posted by nuzzle

My response to this is - lets take C++ at face value. Lets not make it into something it isn't and then blame it for it!

---

I'm not putting the blame on C++, it's just that - nothing in this world is perfect. It's a good thing to understand the tools you're using, so that you can use it as best as possible. That's precisely taking the language at face value.
I've done my best to avoid assigning any non-intrinsic qualities to private inheritance (see above), but as I noted before, we disagree on what exactly these intrinsic qualities are in this case.

Quote:

---

Originally Posted by nuzzle

Secondly, the specific case of private inheritance. You're calling on OO here but the whole idea of OO is to separate design from implementation. And C++ does it nicely. When you're using private inheritance you're in the realms of implementation where C++ grants you the right to do whatever you like including shooting yourself in the foot.

---

And yet, it is the OO community that criticizes the feature the most :D.
Note, however, that you're "in the realms of implementation" only if you're very disciplined about your code. People are rarely very disciplined about anything. But, that's one side of the coin. The other, maybe more important, is the potential extra coupling that can be, in majority of cases, avoided, and that leads to fragile base class type of problems, especially in complex projects. OO and systems design are all about managing complexity.

Quote:

---

Originally Posted by nuzzle

[...] C++ grants you the right to do whatever you like including shooting yourself in the foot.

It's as it should be. In C++ the programmer is king. To put it bluntly, without private inheritance C++ would be reduced to just another Java where the programmer is slave. Who wants that? I've just left Java and I don't want it back!

---

Oh, yeah, I've seen your rant against Java at the Java forums here (:lol:).
Java certainly isn't perfect, and I really can't be the judge of it, but suppose some of the "Java people" have experience in C++ as well... Maybe when they say that you somehow didn't get Java, maybe they have a point. I mean, you really buried it in the mud, so, it's almost hard to believe the situation could really be that bad.
But, I can talk about C# (which "stole" a lot of good ideas from Java, probably from C++ too, and from the overall industry experience i guess). To me, C# is almost like poetry. The programmer is by no means a slave there. But it's not perfect either. On the other hand, I don't really like languages like VB, even if they come in the .NET variant... And I hold C++ at a very highly esteemed 2nd place. BUT, IMO, C++ "kings" have less freedom then they believe. Assembly gives you all the freedom you'd like, but I don't think the programmer is a king there.

Quote:

---

Originally Posted by nuzzle

That's why I think you're wrong. But I don't hate you :).

---

LOL. For, the record, I don't hate you either :D.
But, we disagree, and disagreement is a good thing, as long as it's in a form of a discussion. It's a way to bounce ideas and change perspectives, look at the problem area from different angles, and improve understanding, come closer to the truth. That's what, among other things, forums are for.

Quote:

---

Originally Posted by TheGreatCthulhu

But, we disagree, and disagreement is a good thing,

---

I've expressed my view and I stop here with a few comments.

First my criticism in the Java forum was pertaining to how Sun mismanaged the Java technology for desktop developments. It was not directed at the Java language per se. Java is a nice OO language.

The reason I brought up Java here is because it leans heavily towards the OO paradigm whereas C++ is paradigm agnostic. C++ doesn't enforce a specific paradigm on you. You can mix and match using different paradigms even in the same project. I like that freedom.

And this is also why I react when people critizise a certain C++ language feature, like private inheritance, on the grounds that it doesn't fit their preferred paradigm. C++ is a potent language and you need knowledge and discipline to write good programs. But it would be a mistake to neuter it by removing constructs that don't fit OO. It's been done. It's called Java.

Thanks for this discussion.

Quote:

---

Originally Posted by nuzzle

The reason I brought up Java here is because it leans heavily towards the OO paradigm whereas C++ is paradigm agnostic. C++ doesn't enforce a specific paradigm on you.

---

But of course, this is a vestigial remnant of a decision to maintain backward compatibility with C. I am certain that decision led to the massive adoption of C++ that you see today, but that doesn't mean it was a good choice from a language design point of view. C++ is a powerful language, but is also huge, messy, and packed full of features that are of arguable benefit. Anyway...

Quote:

---

Originally Posted by TheGreatCthulhu

I've taken the liberty of inviting Arjay and BigEd781 to share their opinions in this discussion; my intention wasn't to involve people who would be "on my side" (I don't know their opinions), but I wanted to have some insight into what someone who is highly competent in both C# and C++ thinks of the matter (having experience with two language design philosophies), in the amount of detail they see fit. I think it's valuable to review things from yet another perspective, and I'm hoping they will find time to write down a few thoughts.

---

So hi :).

Because the language does not impose strict rules regarding what you can and cannot do, we are faced with a problem. Sure, one can use (for example) private inheritance any way they wish, but that doesn't mean it is a good idea, and as responsible developers we often create guidelines for how and when they should be used, if at all.

I don't know what was running through Stroustrup's mind when he envisioned private inheritance, so I can't attest to that. I can however speak to the OP's example, in which his Stack type is certainly implemented "in terms of" an std::list. This "Stack" actually *is* a list, it just looks like a Stack from the outside world because of its public interface.

These language constructs were not added to C++ willy nilly (or hell, maybe they were, it sure seems like it sometimes...). The designer(s) certainly had some notion of how they would be used before standardizing them. These days any competent programmer is forced to create a mental model of C++'s features because there are so darn many of them and so darn many gotchas that it is required to build stable and maintainable C++ applications. This is also why many shops only use a subset of C++ features.

So, I agree with Cthulu here; sure, you can use private inheritance any way you like, but that doesn't mean it's a good idea, and that also doesn't mean that there aren't implicit consequences of using it. In most cases it does mean "implemented in terms of" simply because your type takes over the behavior of the base class.

You can shape it to your will if you like, but you can also stir a boiling pot with a closed umbrella and eat soup with a fork. Certainly it is possible, but it may not be wise to do so, and you are obviously fighting against their intended use.

Quote:

---

Originally Posted by BigEd781

But of course, this is a vestigial remnant of a decision to maintain backward compatibility with C. I am certain that decision led to the massive adoption of C++ that you see today, but that doesn't mean it was a good choice from a language design point of view. C++ is a powerful language, but is also huge, messy, and packed full of features that are of arguable benefit. Anyway...

---

That's the kind of sweeping criticism I dislike; C++ should be different, unclear how.

1. The paradigm agnostic nature of C++ has nothing to do with the C connection. C represents procedural programing. In addition you have generics, object orientation and increasingly functional programming. They have nothing to do with the C past of C++.

2. The backward compatibility with C was a stroke of genius. What would've been a better choise? Fortran? Cobol? A brand new language? In hindsight, what other existing language would you say C++ should've better been like? Fine, use it!

3. C++ is complex and that's what makes it powerful. It's not messy, it's complicated because it's complex. And where are all the features of arguable benefit? Mention one (that's not a trivial detail)!

I agree with all of those points to some degree, but they each comes with its own set of drawbacks.

1. Yep, and they are all an afterthought, though still useful.
2. Yes, a good strategic move and very smart, but that doesn't mean it was a goo decision purely in terms of language design. I think it was the right choice, but still, drawbacks.
3. Yep, but it is messy. When you have, multiple ways of doing the same thing it's messy. Name one feature of arguable benefit that creates more problems than it solves? Ok, multiple inheritance.

I use C++ every day. It's a powerful language and it gets the job done, but it's certainly not my goto language if I can avoid it. It's not elegant, it's a sledge hammer. Great when you need a sledge hammer, but otherwise I'll use something more friendly with a more focused design. Anyway, this wasn't meant to be a "C++ is good/bad" debate, just a comment on private inheritance, why it exists, and how it should be used/thought of. I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

Quote:

---

Originally Posted by BigEd781

I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

---

As the person whose retort started this mini-debate, I'd say "quoted for truth". I've read the debate thread cited to me before, but I am not too concerned about it. As I stated in post #5, for the OP, and probably in general, composition "probably (will) be easier for you to think about" than private inheritance. That to me is more important than trying to force a notion of an automatic is-a relationship onto private inheritance and then using that to say that private inheritance should not be used here because it does not model is-a.

Quote:

---

Originally Posted by laserlight

As the person whose retort started this mini-debate, I'd say "quoted for truth". I've read the debate thread cited to me before, but I am not too concerned about it. As I stated in post #5, for the OP, and probably in general, composition "probably (will) be easier for you to think about" than private inheritance. That to me is more important than trying to force a notion of an automatic is-a relationship onto private inheritance and then using that to say that private inheritance should not be used here because it does not model is-a.

---

Well, this mini-debate sort of stopped being about the OP's question, and somehow turned into a discussion about private inheritance...

However, you, and nuzzle it seems, are completely misinterpreting what my concerns are actually about. Yes, I did say that you can't just declare private inheritance - as a language construct - to be completely paradigm agnostic, because it is simply not possible, but that's me nitpicking for purely academic reasons, that is not the point. Private inheritance may have been designed to provide a higher level support for various implementation strategies, but regardless of how you interpret it (as IITO or is-a), it's provides the same internal mechanisms that inheritance does, and that's the problem.

Why. Well, forget private inheritance, and take public inheritance instead. I've already said that OO is all about managing complexity. Why do you think that industry experience strongly advocates not to overuse or misuse inheritance? Because it has hidden pitfalls, subtle interactions that are hard to spot/track/document that, on the long run, have the potential to create a code maintenance hell, reduce reusability, or simply break the code, all because of extra coupling. I've been yelling semantic fragile baseclass problem (sFBC from now on) throughout this thread. Furthermore, I've been consistent in mentioning not sFBC, but sFBC-class of problems - because sFBC is a subset of this group of inheritance-related problems. It's hard for many people to understand what these are actually about, because they are not about compilation problems, or some obvious errors or exceptions. But, I was hoping that experienced developers could have more insight. These are about subclass-baseclass interactions, often indirect, or not obvious via code itself, whereby changes in one could break some invariants in another, or betray some assumptions, thus breaking the code as a whole (it compiles, but God help us with what it does). How? By the simple act of overriding a method, for example. While not overriding another one that is somehow defendant on that one. And not all of these dependencies are obvious or even documented. Or, in the fashion of sFBC, by providing a new version of a baseclass with a seemingly innocent change, that then breaks the client code that relied on a derived class, by breaking an invariant that the derived class assumed.
This is often related to bad design, as well as to client code relying on some implementation detail, maybe for performance reasons - something not uncommon in C++ world.
To read more about this class of problems, namely a subset related to deriving classes safely, see Ruby & Leavens (2000) - Safely Creating Correct Subclasses without Seeing Superclass Code. It's rather academic, and includes reflections on experimental languages, but it explores the problem.
How then should inheritance be used? To see a gallery of proper uses for inheritance, just open Design Patterns by Go4.

Now, back to private inheritance. The recommendation to avoid it unless you really can't is not there without reason. Regardless of how you interpret it (IITO or is-a, or whatever mix seems suitable), it introduces the same problems the public inheritance does. Because, if you're using private inheritance, you are likely to override something, or access a protected member, maybe even introduce new dependencies that can't be represented in syntax. In short, you're introducing the same kind of coupling. It's just how it works.
And only then, on top of that, the construct itself is a bit weird and is something that OO-aware developers are not readily familiar with.

Also, I've been "accused" that I'm forcing specific semantics at private inheritance, but by insisting on IITO, aren't you guys doing the same?
I'm simply saying that there is more to it than you claim, as explained above - which pretty much makes my views broader than yours...
Interestingly enough, in the thread you mentioned, they sort of reached the conclusion that it's better to look at private inheritance from more than one aspect.

What I argue is that:

1. Lack of protected/private inheritance would force less experienced designers to create better designs, or at least to limit themselves to other type of errors. But, since it's already there,
2. it's one of those things that should be used in exceptional situations, because
3. in complex, long running projects, it can be dangerous. Other than that,
4. although it's advocated not to use it, people, among them novices, do.
5. Speaking of novices, they tend to get lost in all the details and intricacies, while loosing the sight of the bigger picture, namely how to design good code.
6. So... Isn't all that indicative that this is not the best language design?

Quote:

---

Originally Posted by nuzzle

That's the kind of sweeping criticism I dislike; C++ should be different, unclear how.

---

I thought this discussion was about understanding all the nuances of protected/private inheritance. On my part, I already said that, despite the claims to the otherwise, C++ programmers would be better off without it, but, since it's already there... Frankly, I'm concerned that you, as C++ developers, aren't too concerned about it.

Quote:

---

Originally Posted by nuzzle

3. C++ is complex and that's what makes it powerful. It's not messy, it's complicated because it's complex. And where are all the features of arguable benefit? Mention one (that's not a trivial detail)!

---

Well, I don't see it that way. It's power comes form relatively few, more or less simple, and well thought of concepts; it's complexity comes from the maturation process.

Quote:

---

Originally Posted by nuzzle

C++ grants you the right to do whatever you like including shooting yourself in the foot

---

The way I see it, C++ grants you an illusion of absolute power and freedom, because you have to invest too much work and have to constantly be on vigil, just so that you don't shoot yourself in the foot - and all that energy could have been better spent.

I like the right amount of control embedded into the design of a language. On the other hand I recognize that there is a fuzzy line between getting the right power/control ratio on one end, and hand-holding on the other - and the latter I dislike. For example, later versions of C# introduced auto properties. In case an explanation is needed - properties are just syntactic sugar for a pair of get/set methods, and as such have a backing member variable. Auto properties remove the need for an explicit backing member variable, behaving as a public member field themselves. This can be handy for trivial getters/setters, but it allready creates some confusion among novice programers. I don't like them [auto-properties] for that fact alone. The need to understand them for what they are distracts them [novices] from much more important stuff.

Final thoughts... Arjay (the other person I invited) and I exchanged a few thoughts via PM, and although he said that he didn't have "anything significant to add publicly", I myself found a few points of interest in the exchange. Among other things, this is what he said that with regard to code maintenance (which he deems very important):
"I think what comes up in practice most is tightly coupled code. Although I code mostly in C# now, I see folks tightly coupling C++ code. [...] The larger the projects the more necessary it is to keep things loosely coupled."

Also:
"Many times in larger projects, I find that inheritance makes everything a pain to work with."

I claim that this coupling is exactly what creates the problems, and I argued that private inheritance (no matter how you view it or define it) has a great potential to create the same kind of coupling.

In closing, I found this interview with Bjarne Stroustrup, a part of which, I think, describes his sentiments about this sort of things. When asked about some potential issues with private inheritance (check the link for details), Stroustrup replied:

Quote:

---

Fundamentally, I consider these these issues purely academic and of no interest to practical programming.

---

Well, that's a rather old-school opinion. Maybe that statement could hold once, but in tomorrow's world, software and software systems are only going to get more and more complex, and interconnected, so I believe that these "purely academic" issues are going to become more and more likely to pop up in the realm of the practical.

Boy, that was a long post.
My intention was to keep it short, but it somehow slipped out of control. :)

as nuzzle said, you are too biased towards an OO-centric view of C++; more specifically, you're reasoning as like inheritance were used in C++ only as a OO-like construction; consider the Sutter's link in post #18: it treats the problem of whether it is better implementing a class by composing with or privately inheriting by another class, where both classes are allowed to change/evolve indipendently. The solution of the problem ( avoiding inheritance in favor of composition ) obviously comes from coupling minimization.
But once you drop the assumption of indipendent evolution of the two classes the conclusion does not hold anymore. Of course, when inheritance models an OO relationship that assumption always holds ( or it's safe to assume so ), but C++ allows non-OO paradigms where that assumption ceases to hold in general.

For example, take a look at the VC++ STL implementation, or (most of) boost source code: (public-private-protected) inheritance is used extensively as a means of organzing class implementations without any devilish side effect on their public interfaces; of course, (nearly) no polymorphic behavior is involved here, we're speaking mainly of generic programming, not OO. Base classes are simply hidden behind some weak incapsulation mechanism ( like a "details" namespace, a standardized interface, etc ... ) and are not allowed changing indipendently with respect to their "implemented on terms of" classes; they're just implementation details, choosen to maximize readibility/mantainability/performance or whatever reason they felt important to do so. For example, it's simply a matter of two mouse clicks to realize that VC++ "std::vector" publicly inherits from "_Vector_val" that in turn publicly inherits from "_Container_base", etc.. nonetheless I've never heard of any insane/novice programmer exploiting those relationships in their code; conversely, those "_Vector_val", "_Container_base", etc.. are simple 2-4 members classes each with its own responsability serving as a simple and effective way of separating the vector implementation in logically distinct but intrinsically coupled parts. No sane-minded mantainer will ever try to modify one of them without knowing their mutual relationships, in the same way no mantainer will ever try to modify a private class member ignoring the overall class implementation.

The point is that the use of inheritance in C++ goes beyond its corresponding OO concept, especially considering the multiparadigmatic nature of C++; therefore, depriving C++ of non-public inheritance ( and other non-OO-friendly language features ) would essentially make C++ an OO language only, or "just another Java", using nuzzle's words :)

of course, you might say that most C++ programmers actually use only a small subset of C++, essentially its OO part. Now, I don't know if this is true or not, as I've never read of any statistics on the subject, but in any case even those programmers indirectly use the full C++ features set through libraries like STL, boost and others extensively exploiting its non-OO features, where there are plenty of things "that OO-aware developers are not readily familiar with" :)

BTW, regarding sFBC-like issues, I've always been surprised of how people gets surprised by these kind of problems ... it seems like there have been a time when developers thought that inheritance were a fool-proof way of adding behavior to a class, only to realize all of a sudden that it was not the case ...

I mean, why considering a "subtle interaction" or a "hidden pitfall" something as obvious as the observation that programmers making unsjustified assumptions on their/others code are programmers writing bad software ? of course, these problems can manifest themselves in hard to spot ways, but this happens nearly everytime you don't follow rules in C++ ... and I'm not saying this is not an issue, I'm saying that this has not specifically to do with inheritance, being a characteristic trait of the language that of being vulnerable to unproper design and/or usage.

Quote:

---

Originally Posted by TheGreatCthulhu

Because, if you're using private inheritance, you are likely to override something, or access a protected member, maybe even introduce new dependencies that can't be represented in syntax.

---

I cannot say I use private inheritance all that often, but in cases where I recall seeing it used, the private base class was not designed to be a public base class: you cannot override something or access a protected member because there are no virtual member functions and all members are either public or private.

In this I echo superbonzo's assertion that, from my point of view, "you are too biased towards an OO-centric view of C++; more specifically, you're reasoning as like inheritance were used in C++ only as a OO-like construction".

Quote:

---

Originally Posted by TheGreatCthulhu

Also, I've been "accused" that I'm forcing specific semantics at private inheritance, but by insisting on IITO, aren't you guys doing the same?
I'm simply saying that there is more to it than you claim, as explained above - which pretty much makes my views broader than yours...

---

Actually, I insisted that private inheritance does not imply is-a and agreed that, in general, private inheritance does mean IITO :)

Quote:

---

Originally Posted by BigEd781

I agree with all of those points to some degree, but they each comes with its own set of drawbacks.

1. Yep, and they are all an afterthought, though still useful.
2. Yes, a good strategic move and very smart, but that doesn't mean it was a goo decision purely in terms of language design. I think it was the right choice, but still, drawbacks.
3. Yep, but it is messy. When you have, multiple ways of doing the same thing it's messy. Name one feature of arguable benefit that creates more problems than it solves? Ok, multiple inheritance.

---

If you want a discussion to stay focused then don't make sweeping controversial statements about other topics.

After your reply I know you're way out for sure:

1. The changes to C++ after its initial release can hardly be considered an afterthought as you claim. It's natural for languages to evolve. The alternative spells stagnation.

2. You claim the C connection was a bad design choise but what exactly would've been better? Some other language that existed at the time? Which? A brand new design? Which?

3. So you feel many ways of doing the same thing is bad? Like if there's a while-statement there shouldn't be a for-statement? What's so bad about choise? You claimed C++ is "packed full of features that are of arguable benefit" and when called for an example the worst you could come up with is multiple inheritance. Well, how bad can it be? It's a cornerstone of OO and both Java and C# have it (although in a milder form).

Quote:

---

I use C++ every day. It's a powerful language and it gets the job done, but it's certainly not my goto language if I can avoid it. It's not elegant, it's a sledge hammer. Great when you need a sledge hammer, but otherwise I'll use something more friendly with a more focused design.

---

More sweeping statements and hand waiving. In your view what's the better language and why?

Quote:

---

I'm not religious about this stuff, but I think that, in general, private inheritance *does* mean "implemented in terms of".

---

Sure, and if you read my posts you'll find that I'm not necessarily opposing that view (from an OO modeling perspective).

Quote:

---

Originally Posted by TheGreatCthulhu

I thought this discussion was about understanding all the nuances of protected/private inheritance.

---

Yes it's about inheritance. The statements you're referring to were replies to BigEd781 and his sweeping statements about C++. I think he's totally wrong and I didn't want to let it pass unchallenged.

Even if you view inheritance from a strict OO perspective (which you really cannot because C++ is multi-paradigmic) there's no particular reason to avoid private inheritance. It can be used to your advantage without any problems at all as long as it's used for implementation convenience only (read code sharing) and as long as the public overall design is done by the book, namely that

- base classes are abstract interfaces, and
- derived classes abide with the Liskov substitution principle.

Tight coupling and brittleness are design issues, not language issues. You can have them in C++ programs but also in Java or C#. They're not resolved by banning language constructs. They're resolved by proper usage of the constructs at your disposal.