This is the mail archive of the 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

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

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