Question: I was reading about [NonVirtual Interface pattern](http://www.gotw.ca/publications/mill18.htm): Herb Sutter is talking about why virtual function must be private in most of the case, protected in some case and never public. 

 But at the end of the article he write:

> 
> Don't derive from concrete classes. Or, as Scott Meyers puts it in Item 33 of More Effective C++,[8] "Make non-leaf classes abstract." (Admittedly, it can happen in practice - in code written by someone else, of course, not by you! - and in this one case you may have to have a public virtual destructor just to accommodate what's already a poor design. Better to refactor and fix the design, though, if you can.)
> 
> 
> 

But I don't understand why this is a poor design

Answer: 
You could buy a copy of *More Effective C++*, or check your local library for a copy, and read item 33 for the full explanation. The explanation given there is that it makes your class prone to partial assignment, also known as slicing:

> 
> There are two problems here. First, the assignment operator invoked on the last line is that of the `Animal` class, even though the objects involved are of type `Lizard`. As a result, only the `Animal` part of `liz1` will be modified. This is a partial assignment. After the assignment, `liz1`'s `Animal` members have the values they got from `liz2`, but `liz1`'s `Lizard` members remain unchanged.
> 
> 
> ￼￼￼￼￼The second problem is that real programmers write code like this. It's not uncommon to make assignments to objects through pointers, especially for experienced C programmers who have moved to C++. That being the case, we'd like to make the assignment behave in a more reasonable fashion. As Item 32 points out, our classes should be easy to use correctly and difficult to use incorrectly, and the classes in the hierarchy above are easy to use incorrectly.
> 
> 
> 

See [this question](https://stackoverflow.com/q/274626/77567) and others for a description of the object slicing problem in C++.

Item 33 also says this, later on:

> 
> Replacement of a concrete base class like `Animal` with an abstract base class like `AbstractAnimal` yields benefits far beyond simply making the behavior of `operator=` easier to understand. It also reduces the chances that you'll try to treat arrays polymorphically, the unpleasant consequences of which are examined in Item 3. The most significant benefit of the technique, however, occurs at the design level, because replacing concrete base classes with abstract base classes forces you to explicitly recognize the existence of useful abstractions. That is, it makes you create new abstract classes for useful concepts, even if you aren't aware of the fact that the useful concepts exist.
> 
> 
>
When you derive from a concrete base class you inherit functionality, which may not be revealed to you if you do not have the source code. When you program to an interface (or abstract class) you don't inherit functionality meaning it it a better way to do things like expose an API. That being said I think that there are plenty of times when inheriting from a concrete class is acceptable