C++ Guidelines

[Pete Vidler]

Hi Folks,

I'm wondering if there is a compilation of C++ guidelines out there
anywhere. Here are some of the ones I've picked up so far (as examples):

- Functions should fit on one screen, from various sources.

- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.

- Virtual methods should be private by default and protected if they
need access to a base classes version (except for the destructor, of
course), from http://www.gotw.ca/publications/mill18.htm.

- Header files should be self contained, from various sources.

- Destructors for base classes should be either virtual or protected.

I think I've probably missed (or never heard of) quite a few more.
Anyone know where I can find such things? Or have some guidelines of
their own to share?

-- Pete

[Pete Vidler]

Claudio Puviani wrote:
[snip]

I've heard of this one, but isn't it seriously out of date?
Good information is never out of date. Knuth's "Art of Computer Programming"
series was first published in 1968 and anyone would get shot for calling it
out of date. A discriminating reader can easily filter out what's still
relevant and what isn't. Those who can't are probably not ready to read the
book yet.

Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?

Knuth's book is somewhat different, the concepts it addresses are not
based on a language that has changed a great deal over time. It isn't
even based on a real language at all (unless you count a few
implementations by enthusiasts).

I've also heard that he has some strange guidelines like
not using namespaces?

EVERY book that proposes guidelines has strange guidelines. Or at least, we
perceive them as being strange because the author comes from a different
background. The thing to remember is that guidelines are NOT rules and
should be followed only if they make sense in a given context.

[snip]

I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptiona l" books to name five) that I have had no
disagreements with at all. I don't believe I come from the same
background as the authors.
The truth is that whether or not one appreciates John's style or agrees with
every detail, anyone who hasn't read the book is a step behind those who
have with regard to physical design.

[snip]

That cannot possibly be true. If we haven't read the book we might still
know everything it contains (through other sources) and not realise it.
And for all I know, if I do read it much of its contents might be
obvious to me.

-- Pete

[Joe Gottman]

"Phlip" <ph*******@yaho o.com> wrote in message
news:IQ******** ****@newssvr15. news.prodigy.co m...

Pete Vidler wrote:

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

If you have code like
class D : public B {};
B * pb = new D();
delete pb;

and D does not have a virtual destructor, undefined behavior results. There
are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus,
you give a class a protected destructor when you don't want anybody deleting
a derived class through a pointer to the base class.

Joe Gottman

[Joe Gottman]

"Phlip" <ph*******@yaho o.com> wrote in message
news:IQ******** ****@newssvr15. news.prodigy.co m...

Pete Vidler wrote:

- Destructors for base classes should be either virtual or protected.

Never heard of the "protected" one.

If you have code like
class D : public B {};
B * pb = new D();
delete pb;

and D does not have a virtual destructor, undefined behavior results. There
are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus,
you give a class a protected destructor when you don't want anybody deleting
a derived class through a pointer to the base class.

Joe Gottman

[Phlip]

Joe Gottman wrote:

If you have code like
class D : public B {};
B * pb = new D();
delete pb;

and D does not have a virtual destructor, undefined behavior results. There are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus, you give a class a protected destructor when you don't want anybody deleting a derived class through a pointer to the base class.

The rules for 'protected' roughly mean "anything you could reference thru
'this' (plus statics)".

So 'delete this' breaks your protection.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Joe Gottman wrote:

If you have code like
class D : public B {};
B * pb = new D();
delete pb;

and D does not have a virtual destructor, undefined behavior results. There are two possible solutions to this. If you give B a virtual destructor,
the correct destructor is called by delete. Alternatively, if you give B a
protected destructor the "delete pb;" statement will fail to compile. Thus, you give a class a protected destructor when you don't want anybody deleting a derived class through a pointer to the base class.

The rules for 'protected' roughly mean "anything you could reference thru
'this' (plus statics)".

So 'delete this' breaks your protection.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Pete Vidler wrote:

Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?
What you need is not in any book.

From Lakos, you will learn dozens of very valid guidelines. For example, the
first #include line inside foo.cpp should always be foo.h. This ensures that
foo.h can stand alone without any other header above it - no surprise
requirements.

From Knuth, you will learn how to think and reason much harder than is
usually needed. These are just warmups for thinking outside the box, and
going off one of Knuth's diagrams.

Also (if Pete Becker isn't around and it's safe to mention this), read the
Sedgewick books on algorithms.
Knuth's book is somewhat different, the concepts it addresses are not
based on a language that has changed a great deal over time. It isn't
even based on a real language at all (unless you count a few
implementations by enthusiasts).
So is /Design Patterns/. There is no book that says "How can Pete Vidler use
the latest language features safely". Not even /Modern C++ Design/ by Andrei
Alexandrescu, which covers templates in greater detail than mere mortals
need.
I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptiona l" books to name five) that I have had no
disagreements with at all. I don't believe I come from the same
background as the authors.

This misses the point. Lakos says "I analyzed my huge project like this, and
I found these conclusions". Many of his recommendations are perfect, but
many are simply the result of his project. Learn from how he analyzed the
project.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Pete Vidler wrote:

Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?
What you need is not in any book.

From Lakos, you will learn dozens of very valid guidelines. For example, the
first #include line inside foo.cpp should always be foo.h. This ensures that
foo.h can stand alone without any other header above it - no surprise
requirements.

From Knuth, you will learn how to think and reason much harder than is
usually needed. These are just warmups for thinking outside the box, and
going off one of Knuth's diagrams.

Also (if Pete Becker isn't around and it's safe to mention this), read the
Sedgewick books on algorithms.
Knuth's book is somewhat different, the concepts it addresses are not
based on a language that has changed a great deal over time. It isn't
even based on a real language at all (unless you count a few
implementations by enthusiasts).
So is /Design Patterns/. There is no book that says "How can Pete Vidler use
the latest language features safely". Not even /Modern C++ Design/ by Andrei
Alexandrescu, which covers templates in greater detail than mere mortals
need.
I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptiona l" books to name five) that I have had no
disagreements with at all. I don't believe I come from the same
background as the authors.

This misses the point. Lakos says "I analyzed my huge project like this, and
I found these conclusions". Many of his recommendations are perfect, but
many are simply the result of his project. Learn from how he analyzed the
project.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Siemel Naran]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote in message
news:OVZdc.83$7 w.18@newsfe1-

Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".

bool C::operator==(c onst C& that) const {
if (typeid(*this) != typeid(that)) return false;
return this->doequal(that );
}

bool C2::doequal(con st C& arg) {
const C2& that = static_cast<con st C2&>(arg);
...
}

Here C2 derives from C, and C::doequal is pure virtual. Though a double
dispatch mechanism might more elegant. Granted an operator== doesn't always
make sense.

[Siemel Naran]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote in message
news:OVZdc.83$7 w.18@newsfe1-

Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".

bool C::operator==(c onst C& that) const {
if (typeid(*this) != typeid(that)) return false;
return this->doequal(that );
}

bool C2::doequal(con st C& arg) {
const C2& that = static_cast<con st C2&>(arg);
...
}

Here C2 derives from C, and C::doequal is pure virtual. Though a double
dispatch mechanism might more elegant. Granted an operator== doesn't always
make sense.

[Claudio Puviani]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote

Claudio Puviani wrote:
[snip]

I've heard of this one, but isn't it seriously out of date?
Good information is never out of date. Knuth's "Art
of Computer Programming" series was first published
in 1968 and anyone would get shot for calling it out
of date. A discriminating reader can easily filter out
what's still relevant and what isn't. Those who can't
are probably not ready to read the book yet.

Right, but if it almost pre-dates namespaces there is
going to be a lot missing from it -- am I right?
Templates and such?

First of all, it doesn't predate namespaces, much less templates. It's not a
book about individual C++ features. If that's what you're looking for, this
is the wrong book for you. It's about large-scale software design, and the
basic principles can be applied to almost any language.
Knuth's book is somewhat different, the concepts it
addresses are not based on a language that has changed
a great deal over time. It isn't even based on a real
language at all (unless you count a few implementations
by enthusiasts).
Software design is fairly language-independent as well. John Lakos simply
used C++ as an example because it's still the best vehicle for large scale
software development.

I've also heard that he has some strange guidelines like
not using namespaces?

EVERY book that proposes guidelines has strange guidelines.
Or at least, we perceive them as being strange because the
author comes from a different background. The thing to
remember is that guidelines are NOT rules and should be
followed only if they make sense in a given context.

[snip]

I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptiona l" books to name five) that I have
had no disagreements with at all. I don't believe I come from
the same background as the authors.

You're a rare exception. Most people have built up equally valid guidelines
over years of developing in C++, and it's just impossible for every rule in
every book to seemlessly fit into every other system. It's not a criticism
of the authors; just situations that make some recommendations inapplicable
or inconsistent with existing practices.

The truth is that whether or not one appreciates John's style
or agrees with every detail, anyone who hasn't read the book
is a step behind those who have with regard to physical design.

[snip]

That cannot possibly be true. If we haven't read the book we
might still know everything it contains (through other sources)
and not realise it.

That's highly unlikely and slightly pretentious. The best software
developers I know -- and I know some stellar ones -- still learn something
every time they pick up a new book. Anyone who thinks he's too good to learn
something new is just plain delusional.
And for all I know, if I do read it much of its contents might be
obvious to me.

Right. Maybe you should read it instead of patting yourself on the back
prematurely.

Claudio Puviani