Effective C++: discouraging protected inheritance?

Question

I was reading Scott Meyers\' Effective C++ (third edition), and in a paragraph in Item 32: Make sure public inheritance is \"is-a\" on page 151 he make

Answer 1

Some scenarios where you'd want protected:

1. You have a base class with methods where you know you never want to expose the functionality outside, but you know will be useful for any derived class.

2. You have a base class with members that should be logically used by any class that extends that class, but should never be exposed outside.

Thanks to multiple inheritance you can play around with base classes' inheritance type and construct a more diversed class with existing logic and implementation.

A more concrete example:

You could create a few abstract classes that follow Design Pattern logic, lets say you have:

Observer
Subject
Factory

Now you want these all to be public, because in general, you could use the pattern on anything.

But, with protected inheritance, you can create a class that is an Observer and Subject, but only protected factory, so the factory part is only used in inherited classes. (Just chose random patterns for the example)

Another example:

Lets say for example you want to inherit from a library class (not that I encourage it). Lets say you want to make you own cool extension of std::list<> or a "better" shared_ptr.

You could derive protectedly from the base class (which is designed to have public methods).
This will give you the option to use your own custom methods, use the class' logic, and pass the logic to the to any derived class.

You could probably use encapsulation instead, but inheritance follows the proper logic of IS A (or in this case IS sort of A)