This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using C++ in GCC is OK


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]