On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor <i...@google.com> wrote: > 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.
I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. Richard. > Ian >
