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

[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

[Rob Williscroft]

Phlip wrote in news:cL******** ********@newssv r32.news.prodig y.com in
comp.lang.c++:

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.

It calls D's dtor, since that is the type of *this.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Rob Williscroft]

Phlip wrote in news:cL******** ********@newssv r32.news.prodig y.com in
comp.lang.c++:

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.

It calls D's dtor, since that is the type of *this.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Steven T. Hatton]

Pete Vidler wrote:

Claudio Puviani wrote:
[snip]

It has rudimentary design guidelines as well. The formatting section is
just a few pages, and the least interesting at that.

But how rudimentary? I can't possibly buy a book on the off-chance it
might contain what I need (I couldn't afford it). I can't find any
actual reviews of the book, and the only info in the summary suggets the
book is about formatting/naming conventions (useless to me).

Here's a list of books I posted once before that would give you what you
need:

Cool, thanks. I have read most of these, but there are one or two on
that list I haven't seen before.

-- Pete

I never bought that particular book, but I have the Java counterpart. I
assume they are comperable. It's probably not the one book you are looking
for. OTOH, there is something to be said for the relationship between
programming style and design approach. To some extent good style produces
good design by default.

One of the best lessons I ever learned was something someone told me about
how to stack boxes in a warehouse. If there is some obvious pattern
available follow it. Things will simply fall into place. So, you stack
all the boxes so the same face (the picture of the product, for example) is
oriented identically for all boxes. The principle has far reaching
consequence on how smoothely the overall processes work.

But, I believe you are looking for just about the same kind of resource I
have been wanting. Have you found a winner yet?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Pete Vidler wrote:

Claudio Puviani wrote:
[snip]

It has rudimentary design guidelines as well. The formatting section is
just a few pages, and the least interesting at that.

But how rudimentary? I can't possibly buy a book on the off-chance it
might contain what I need (I couldn't afford it). I can't find any
actual reviews of the book, and the only info in the summary suggets the
book is about formatting/naming conventions (useless to me).

Here's a list of books I posted once before that would give you what you
need:

Cool, thanks. I have read most of these, but there are one or two on
that list I haven't seen before.

-- Pete

I never bought that particular book, but I have the Java counterpart. I
assume they are comperable. It's probably not the one book you are looking
for. OTOH, there is something to be said for the relationship between
programming style and design approach. To some extent good style produces
good design by default.

One of the best lessons I ever learned was something someone told me about
how to stack boxes in a warehouse. If there is some obvious pattern
available follow it. Things will simply fall into place. So, you stack
all the boxes so the same face (the picture of the product, for example) is
oriented identically for all boxes. The principle has far reaching
consequence on how smoothely the overall processes work.

But, I believe you are looking for just about the same kind of resource I
have been wanting. Have you found a winner yet?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Pete Vidler wrote:

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

Zawinski is known for being a bit off the wall, but he also wrote everything
from the keycaps program, through a good deal of the XEmacs code, and to a
lot of the code in the original Mozilla (aka Netscape). Consider the love
affair between Netscape and Microsoft when you read his review of _Writing
Solid Code_:

http://www.mozillazine.org/resources...ndations1.html

I haven't read any of the books cover to cover, and cannot provide
assessments of the reviews. It just seemed like a resource worth sharing.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Pete Vidler wrote:

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

Zawinski is known for being a bit off the wall, but he also wrote everything
from the keycaps program, through a good deal of the XEmacs code, and to a
lot of the code in the original Mozilla (aka Netscape). Consider the love
affair between Netscape and Microsoft when you read his review of _Writing
Solid Code_:

http://www.mozillazine.org/resources...ndations1.html

I haven't read any of the books cover to cover, and cannot provide
assessments of the reviews. It just seemed like a resource worth sharing.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Pete Vidler]

Claudio Puviani wrote:
[snip]

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.

What I am looking for is what I posted originally -- guidelines similar
to the ones I posted. I'm not looking for a book describing individual
C++ features, but rather a book describing (the authors) best practices
in /using/ them.

[snip] 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'm not looking for software design info (large scale or otherwise), but
guidelines on using C++ effectively.

[snip] 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.

Fair enough.

[snip]

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.

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.

Did I say I thought I was too good to learn something new? Would I have
even sent my original post if I thought that?

I don't care how good someone is at software development, even beginners
could pick up a book and find they already know the info it contains.
It's a distinct possibility with so many books, articles, web pages, etc
covering the same topics.

I'm fairly sure I could read a beginners C++ guide and learn nothing
that I didn't already know. That doesn't mean that I believe this of all
books.

Note that none of this reflects on the book in question. I have not read
it so I cannot possibly say. My purpose in asking these questions about
it was not to insult anyone, or to imply that it is not worth reading --
I am just trying to establish if it meets my needs.

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.

I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete

[Pete Vidler]

Claudio Puviani wrote:
[snip]

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.

What I am looking for is what I posted originally -- guidelines similar
to the ones I posted. I'm not looking for a book describing individual
C++ features, but rather a book describing (the authors) best practices
in /using/ them.

[snip] 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'm not looking for software design info (large scale or otherwise), but
guidelines on using C++ effectively.

[snip] 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.

Fair enough.

[snip]

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.

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.

Did I say I thought I was too good to learn something new? Would I have
even sent my original post if I thought that?

I don't care how good someone is at software development, even beginners
could pick up a book and find they already know the info it contains.
It's a distinct possibility with so many books, articles, web pages, etc
covering the same topics.

I'm fairly sure I could read a beginners C++ guide and learn nothing
that I didn't already know. That doesn't mean that I believe this of all
books.

Note that none of this reflects on the book in question. I have not read
it so I cannot possibly say. My purpose in asking these questions about
it was not to insult anyone, or to imply that it is not worth reading --
I am just trying to establish if it meets my needs.

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.

I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete

[Pete Vidler]

Steven T. Hatton wrote:
[snip]

But, I believe you are looking for just about the same kind of resource I
have been wanting. Have you found a winner yet?

Of the books I have read so far, the following have been extremely useful:

Effective C++
More Effective C++
Effective STL
Exceptional C++
More Exceptional C++

.... not exactly guideline books, but still good: TC++PL, Design
Patterns, Modern C++ Design, etc.

And the articles at www.gotw.ca are good. Also, there are many good
articles at www.cuj.com (if you dig around the archives).

Other than that I have found very little.

-- Pete