> 2) The parent class does not consist only of pure virtual methods. > In that case I am arguing that all virtual methods should be > protected.
What about the case where the parent provides default implementations of methods that are infrequently overridden by children? Otherwise, you end up with cases where every child class needs to implement every virtual method, whether it needs to for its own purposes or not. Your proposal forbids the case where a child is just like the parent, "except that this method is a little different...", which describes a lot of useful heirarchies. The gcc example would be the RTL base class defining RTL::reg_p() to return false, and having the one class that is a reg redefine it to return true. > The reason for the latter case is that the parent class is providing > a public interface, and it is doing so by using a separate interface > defined by child classes. The two interfaces are obviously related, Maybe you and I have completely different ideas about how the whole class heirarchy works. I'm not a firm believer that the base-most class should be an empty shell of a class that does nothing but provide a placeholder for umpteen direct-but-leaf derived classes. A base class is simply a more generic representation of data (and may be derived from something even more generic), and derived classes are more specific representations (and may be inherited by even more specific representations). > there should be a public method which calls the protected method. I suggest this is arbitrary and unneeded. Having a foo_public() that just calls foo_protected() is a waste of time (and means you have to come up with two unique names for the same function), just move the foo() into the public space. > In particular, as new child classes are implemented and the parent > class interface evolves, they evolve in different ways. Keeping the > two interfaces separate from the start avoids confusion and makes it > easy to redesign either interface separately from the other one. I recognize that there's an API between the classes and the rest of the world, and a separate API between a base class and its children. I disagree that we should force any given class to have one or the other but not both. > I don't see why the coding standard should prohibit using a good > editor, but I'm willing to hear what other people think. It's not about prohibiting a good editor, it's about prohibiting a not-as-good-as-yours editor.
