> 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.
> > * 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().
> Our current code always uses the equivalent of an explicit this
> pointer, except that it is called something else.
Our current code is also written in C, and we're trying to move away
from that limitation...
> The biggest need for this-> is when calling methods in the current
> class if the current class happens to be in a template.
I generally avoid classes-in-templates. That road leads to confusion
pretty easily. If a design *requires* a "this->", I'd say the design
is defective and the code should be rewritten.
> > * 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.
