Scott Meyers on Programming C++

Bill Venners writes "Artima.com has published a four-part interview with Scott Meyers, author of Effective C++, More Effective C++, and Effective STL. In Multiple Inheritance and Interfaces, Scott describes how his view of multiple inheritance has changed with time, the C++ community's take on Java's interface, and a schism of focus between the C++ and other prominent development communities. In Designing Contracts and Interfaces, Scott discusses interface contracts, private data, and designing minimal and complete interfaces. In Meaningful Programming, Scott discusses the importance of saying what you mean and understanding what you say, the three fundamental relationships between classes, and the difference between virtual and non-virtual functions. In Const, RTTI, and Efficiency, Scott describes the utility of const, the appropriate time to use RTTI, a good attitude about efficiency, and Scott Meyers' current quest for general programming principles."

Comments

Meyer's books on C++

[Henry V .009]

I own each of Meyer's books, and they are all wonderful. If you work with C++ in any sort of professional capacity get a hold of copies right now.

Best quote from the extended interview

[Lumpish Scholar]

Meyers: "... we have templates in C++, but there's no way to write user interfaces or talk to databases. Java has no templates, but you can write user interfaces up the wazoo and you can talk to databases with no trouble at all."

public final static variables in interfaces (was R

[fingal]

Does anyone know why interfaces have data members at all?

It can be a very useful way of exposing constants. For example, consider the following:-

public interface VariableList {
public final static String VAL1 = "val1";
public final static String VAL2 = "val2";
public final static String[] VAL_ARRAY = { VAL1, VAL2 };
public final static List VAL_LIST = Collections.unmodifiableList( Arrays.asList( VAL_ARRAY ) );
}

This will provide you with a slightly more flexible set of constants that are automatically acquired by anything that implemnts the VariableList interface.

Alternatively, you can use Mutable variables. Remember that it is only the references to the variable that is final. If the Object itself contains information then it accessed by all classes that implement the interface. For example:-

public interface CountMe {
public Set INSTANCES = new Set();
}

If we now stipulate that all instances of CountMe that want to be included in the CountMe functionality should register themselves inside the INSTANCES variable, for example:-

import java.util.*;

public class Test {

public Test() {
Class1 class1 = new Class1();
Class2 class2 = new Class2();
Iterator instances = class1.INSTANCES.iterator();
while( instances.hasNext() ) {
System.out.println(instances.next());
}
}

public interface CountMe {
public Set INSTANCES = new HashSet();
}

public class Class1 implements CountMe {
public Class1() {
INSTANCES.add(this);
}
}

public class Class2 implements CountMe {
public Class2() {
INSTANCES.add(this);
}
}

public static void main(String[] args) {
new Test();
}
}

and there you have it - data sharing across interfaces with no extending classes at all. Of course, you cannot force classes to register themselves in the INSTANCES variable, but if you wanted to extend a couple of base classes then it would be trivial to make a couple of implementations of CountMe that extend each of them which enforce the functionality explicitly.

Re:Good articles

[fingal]

I actually think of this as an indicator of Bad design. Use of symbolic constants, especially as a replacement for Enum, is a serious breach of OO design in most cases. Static immutable instances of classes that the enum represents are quite often a better way to go.

The Static immutable instances of classes gets half-way there, but doesn't stop people creating new instances of the classes and then you are back where you where to begin with. A better thing to do is to forcibly limit the instances of the classes to a fixed number of instances like so:-

public class MyEnum {
private MyEnum() { }
public final static MyEnum OPTION1 = new MyEnum();
public final static MyEnum OPTION2 = new MyEnum();
public final static MyEnum OPTION3 = new MyEnum();
}

Now you are guaranteed that there is only ever going to be MyEnum.OPTION1, MyEnum.OPTION2 and MyEnum.OPTION3.

I've always thought Meyers was wrong about MI...

[swillden]

... and this article has helped me to understand precisely why we disagreed. And he's still wrong, although he's getting closer.

I've been writing C++ code professionally since about 91, when Scott published his first book. I think I was lucky that I didn't come across his book for a few years, particularly because of his skepticism of MI. I might have followed his advice and my career would have been the worse for it.

I have always made heavy use of MI in my code, and 80% of the time I've written C++ classes that are exactly analogous to Java interfaces; it just always seemed like a good idea to me. Also, I was a big fan of Robert C. Martin and his notions about how you can analyze design quality by looking at the abstractness of the classes and the dependencies between them (dependencies on abstract classes, especially pure abstract classes(*) are, much better than dependencies on classes that do a lot of stuff for the simple reason that classes that do a lot have more potential to change, so purely abstract firewalls tend to limit the ripple effect).

To avoid self-aggrandizement, I didn't independently invent the notion of pure abstractions. I had fiddled with Objective-C and it had a construct (whose name I forget) that allowed you to define a pure interface. You could then use that pure interface type as a function parameter and the compiler would verify that objects you passed to that function met the interface requirements -- allowing you to get compile-time typechecking in an otherwise completely dynamically-typed language.

However, as I said, I think only about 80% of my MI usage is with pure abstractions. Probably 10% of the time I use MI, I do it to facilitate a style of programming called "mix-in" programming. The idea is that you have a bunch of purely abstract classes that define the potential interfaces, and you have a bunch of concrete classes that implement the pure abstractions in various useful ways and then you can create useful classes by mixing together appropriate base classes (with the occasional bit of glue). Mix-ins aren't appropriate for everything, but they can be a very elegant solution for many toolkit kinds of scenarios. Diamond inheritance doesn't really happen, because none of the mixed-together classes have enough code in them to make it worth inheriting from them. If you need something almost like one mixed-together class, you just mix a completely new one.

In practice, not only do pure abstractions and mix-ins sidestep all of the "problems" that make people leery of MI, they're also not at all confusing to less competent programmers. I've found that with just the tiniest explanation of how the structure is put together, people can see immediately how it works and why it's good (well, once they've understood the idea of polymorphism, anyway).

I think C++ MI can also be used more fully to good effect, but that must, indeed, be done judiciously.

(*) Scott said in the interview that the C++ community doesn't have a name for interface classes. Maybe not, but I've been using the term "pure abstract class" for close to a decade and I don't think I've come across a single marginally-competent C++ programmer who didn't immediately understand the term, and I'm pretty sure I picked the term up from comp.lang.c++.

C++ community not using interfaces?

[spongman]

But I would say that while the C++ community was focusing on templates, the STL, and exceptions... what they were not doing was component-based development.

I don't know where Scott's been for the last 10 years but COM specifically uses multiple inheritance of abstract base classes without data or implementation to specify interfaces for component-based development (and I believe that CORBA does the same).

I'd guess that win32 C++ programmers make up the largest such subset of all C++ programmers. So which C++ community is he talking about exactly?