Stack/Queue Question

[TheGreatCthulhu]

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.

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.