DJ Delorie <d...@redhat.com> writes: >> I did mean that all virtual functions should be protected. > > This forbids the most useful thing about virtual functions - letting > child classes implement a public ABI defined by the base class.
There are really two cases to consider, and actually the coding standard should describe this. 1) The parent class consists only of pure virtual methods. In that case it is perfectly reasonable for those methods to be public. 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. In cases where the virtual method implements something which is part of the public interface, there should be a public method which calls the protected method. 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, but they are not the same. 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. >> > * All data members should be private. >> > * All data members should have names which end with an underscore. >> > >> > This makes all structures illegal. I'd remove the first "All" and >> > replace the second with "Private": >> >> This text only refers to classes. As the convention says in the >> following major bullet, structs are handled as they are today. > > I don't agree that *all* data members of classes should be private. > It's not always appropriate - it depends on the design of the class. > I'd hate to be forced to do this for every datum: > > int count; > int get_count (); > void set_count (int); > > That gets messier when the datum are pointers. foo->bounds->left is > cleaner than foo->get_bounds()->get_left(). I think I'm advocating a reasonable position here. With our current data structures such as tree and rtx, we generally do not use direct field access, but always use accessors. For cases where direct field access is appropriate can use structs. What do other people think? >> > * Use C-style comments for multi-line comments, and C++-style comments >> > for single-line comments. >> >> I'm not sure i agree with this, because I don't see anything wrong >> with multi-line C++-style comments. > > It assumes your editor can do block-reformatting while preserving the > comment syntax. I've had too many // cases of Emacs guessing wrong // > and putting // throughout a reformatted // block. I don't see why the coding standard should prohibit using a good editor, but I'm willing to hear what other people think. Ian
