I once had a discussion with other programmer who claimed that interfaces are bad programming practice in C++. I have ordered most well-known and respected books about C++ and looked for quotations corresponding to my question:
Is it a good programming practice to have interfaces?
Are they commonly used?
Let the masters speak.
Bjarne Stroustrup, The C++ Programming Language, Addison Wesley, 2006, chapter 25.3, page 769:
The simplest way of loosening the coupling between users of a class and its implementation and also between code that creates objects and code that uses such objects is to introduce an abstract class that represents the interface to a set of implementations of a common concept.
(…) To sum up, an abstract type aims to:
[1] define a single concept in a way that allows several implementations of it to coexist in a program [this is what’s needed for unit testing]
[2] provide a reasonable run-time and space efficiency through the use of virtual functions
[3] let each implementation have only minimal dependency on other classes; and
[4] be comprehensible in isolation
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison Wesley, 2005, chapter 1 (“Introduction”), page 18:
There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes:
1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.
2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design:
Program to an interface, not an implementation
Don’t declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book.
Bruce Eckel, Thinking in C++, vol. 1, Second Edition, Prentice Hall, chapter 15 (“Polymorphism & Virtual Functions”), page 646
Abstract base classes and pure virtual functions
Often in a design, you want the base class to present only an interface for its derived classes. That is, you don’t want anyone to actually create an object of the base class, only to upcast it to so that its interface can be used. This is accomplished by making that class abstract, which happens if you give it at least one pure virtual function. (…)
(…) The only reason to establish the common interface is so it can be expressed differently for each different subtype. It creates a basic form that determines what’s in common with all of the derived classes ― nothing else.
Bruce Eckel, Thinking in C++, vol. 2, Prentice Hall, chapter 9 (“Multiple Inheritance”, “Interface Inheritance”), page 576
Interface inheritance, on the other hand, only adds member function declarations to a derived class interface and is not directly supported in C++. The usual technique to simulate interface inheritance in C++ is to derive from an interface class, which is a class that contains only declarations (no data or function bodies). These declarations will be pure virtual functions, except for the destructor. (…)
Herb Sutter, Andrei Alexandrescu, C++ Coding Standards, Addison Wesley, 2004, chapter “Class Design and Inheritance”, page 62.
36. Prefer providing abstract interfaces
Summary
Love abstract art: Abstract interfaces help you focus on getting an abstraction right without muddling it with implementation or state management details. Prefer to design hierarchies that implement abstract interfaces that model abstract concepts.Discussion
Prefer to define and inherit from abstract interfaces. An abstract interface is an abstract class made up entirely of (pure) virtual functions and having no state (member data) and usually no member function implementations. Note that avoiding state in abstract interfaces simplifies the entire hierarchy design (see [Meyers96] for examples).
In conclusion, interfaces in C++, expressed as pure abstract classes, are recommended and commonly used.
Maciej Bliziński 
Yes, interfaces are the way to go for all but the simplest projects. Here’s a practical example.
I’m working on a multi-tier web application, and we have a presentation layer, a business layer, and a data access layer. We designed the presentation layer around business layer interfaces, but we allowed the data access layer “friend” access into the business layer so that it could set shadow attributes and keep bookkeeping information for the database.
Unfortunately, the design also called for the business objects to be wrapped in proxies which weren’t ready until later. When the proxies were finally turned on, the presentation layer worked as before. However, the data access layer didn’t, because the data access layer was casting business objects to implementation classes in order to access the shadow attributes. When all of a sudden they were proxies, kaboom!
We were fortunate however that the “friend” access we were using was very interface-like in style, so it was an almost mechanical exercise in writing service interfaces to the backside of the business layer, and we were up and running again after only a few days. But if it were a bigger project, or if the proxies had been longer delayed, there would have been some real risk of slippage in the project.